53 votes

Proposer des demandes de fonctionnalités à l'équipe R Core

Quelle est la méthode recommandée pour contacter l'équipe R Core afin de proposer des demandes de fonctionnalités ?

Par "demandes de fonctionnalités", je n'entends pas simplement le fait de tirer quelque chose comme "J'aimerais que la fonctionnalité XY fasse XY, donc ce serait cool si vous alliez de l'avant et l'implémentez pour moi" mais plutôt de proposer du code réel.

J'aime R et je suis prêt à contribuer, à partager le code et tout le reste. Pourtant, j'ai parfois un peu de mal à comprendre ce qu'est exactement R. comment pour contribuer ;-) J'ai regardé le Page du développeur du projet R et utilisé la liste de diffusion r-devel à quelques reprises. En ce qui concerne cette dernière, j'ai eu l'impression que ce n'était pas le bon endroit ou que ce n'était pas souhaitable pour élaborer une demande de fonctionnalité avec du code réel (qui peut parfois être plus qu'une simple ligne de deux lignes). Je me demande donc s'il n'y a pas une "meilleure" façon ou une façon plus "systématique" de le faire.

MODIFIER 2011-11-09

On m'a demandé de fournir un bref exemple :

J'utilise beaucoup les classes de référence S4 et j'ai implémenté un grand nombre de petites fonctions utilitaires pour mes objets. L'une de ces fonctions utilitaires est une sorte de fonctionnalité de "réinitialisation" :

setRefClass(
    "A", 
    fields=list(a="numeric", b="character"),
    methods=list(
        reset=function(fields=NULL, ...){
            temp <- new("A")
            if(is.null(fields)){
                fields <- names(getRefClass("A")$fields())
            }
            sapply(fields, function(x){
                .self$field(name=x, value=temp$field(x))        
            })
            return(TRUE)
        }
    )
)

x <- new("A", a=1:10, b=letters[1:10])

x$a
x$b
x$reset(fields="a")

x$a
x$b

x$reset()
x$a
x$b

Très souvent, ce n'est pas la fonction la plus sophistiquée du monde qui apparaît sur ma liste de "oh, ça manque". De plus, il peut s'agir d'une fonction tellement "singulière" que le développement d'un ensemble complet donne parfois l'impression de casser la noix avec un marteau de forgeron.

0 votes

Je vote pour classer cette question comme hors-sujet car elle ne concerne pas la programmation. Pourquoi nous ne sommes pas le service clientèle de votre entreprise préférée ? .

0 votes

@JasonMArcher : assez juste, même si je suis content que la question reste posée (parce qu'elle est en fait utile, même si elle est hors sujet). (Votre lien semble un peu hors sujet, bien que je suppose qu'à la limite on pourrait considérer cette question comme une question de "support client" ...) (Avez-vous downvoté toutes les réponses ici ? Elles ont chacune exactement un downvote ... si c'est le cas, cela semble un peu extrême puisque le downvote est (je suppose) censé indiquer que la réponse n'est "pas utile" ...)

0 votes

Je vote pour classer cette question comme hors-sujet car elle ne concerne pas la programmation.

39voto

Ben Bolker Points 50041

C'est une excellente question. Bien que j'aime beaucoup R, je trouve son modèle de développement parfois frustrant. Je dirais que les meilleures options sont

  1. (Basé sur un commentaire de @Matifou) Vérifiez si votre idée a été discutée précédemment sur r-devel@r-project.org . Bien que les archives ne proposent pas d'interface de recherche, vous pouvez effectuer une recherche Google avec le préfixe site:stat.ethz.ch/pipermail/r-devel (par exemple site:stat.ethz.ch/pipermail/r-devel sweep ). Nabble fournit également une interface de recherche, mais elle est laide et pleine de publicités ...
  2. Postez l'idée initiale (sans code étendu) sur R-devel et voyez si vous pouvez susciter la discussion/enthousiasme. Il faut être prêt à pousser : par exemple, j'ai réussi à faire intégrer un contrôle d'erreur supplémentaire dans sweep il y a quelques années (pour qu'il se plaigne réellement des dimensions non concordantes plutôt que de renvoyer silencieusement la mauvaise réponse), mais seulement après avoir proposé l'idée, attendu une semaine, relancé l'idée, envoyé un code prototype, testé pour s'assurer qu'il ne causait pas de problème de performance, discuté à nouveau...
  3. mettre en œuvre votre idée en tant que paquet complémentaire. Cela est bien sûr beaucoup plus difficile si ce que vous proposez est une modification de la fonctionnalité de base de R (d'un autre côté, ce type de modification sera également beaucoup plus difficile à faire accepter). D'un autre côté, vous pouvez implémenter à peu près tout ce que vous voulez dans un paquet complémentaire, et cela présente plusieurs avantages. (1) Votre code sera disponible pour que tout le monde puisse l'utiliser immédiatement (si vous le publiez sur R-forge, Rforge, GitHub ou CRAN) ; (2) c'est un moyen pour que les idées soient développées et affinées. sans (3) même s'il n'est jamais accepté dans R-core, il sera toujours disponible en tant que paquet.
  4. Essayez de trouver un utilitaire existant ou un paquet "misc" auquel contribuer (par exemple, j'ai contribué au paquet "misc" de Jim Lemon). plotrix qui est une compilation de petits utilitaires de traçage), et contactez le mainteneur/auteur.
  5. Publiez les éléments de votre liste de souhaits dans le système de suivi des bogues de R (en joignant le code, etc.). Cependant, ils seront vus par beaucoup moins de personnes que si vous utilisez les options 1 ou 2, et par conséquent, ils risquent davantage de languir dans le bug tracker sans jamais voir la lumière du jour.

1 votes

J'ai commencé à écrire mes propres paquets. Pourtant, je tombe souvent sur quelque chose de si petit qui ne justifierait pas vraiment un paquet à lui tout seul. Bien sûr, vous pouvez toujours résoudre ce problème en publiant "encore un autre paquet utilitaire", mais je me demande si c'est vraiment la voie à suivre car vous perdez facilement le fil, les gens utilisent des conventions différentes, le problème du masquage (que je trouve terrible car parfois vous ne savez même pas qu'il est arrivé jusqu'à ce que vous ayez besoin de remanier votre code ;-)) et ainsi de suite...

0 votes

Voir la suggestion (révisée) n° 3 ci-dessus. Dans l'exemple que vous donnez, je posterais probablement sur R-devel, en demandant si quelqu'un travaille sur un paquetage utilitaire approprié. En postant sur r-devel, vous pourriez également attirer l'attention de John Chambers, qui est, je crois, le principal développeur des classes de référence...

0 votes

Bonne réponse. J'ajouterais qu'une bonne soumission de code ne contient pas seulement du code, mais aussi une documentation de haute qualité ainsi que du code de test automatisé (le cas échéant).

27voto

Gavin Simpson Points 72349

Il est très peu probable que de nouvelles fonctionnalités soient intégrées dans la base R elle-même, sauf si i) elles suscitent l'intérêt d'un membre de l'équipe de développement de base de R, ou ii) il s'agit d'une extension d'une fonctionnalité existante qui améliore son fonctionnement ou la rend plus efficace. et un membre de R Core est suffisamment intéressé. Vous pouvez bien sûr déposer un bogue sous la rubrique Liste de souhaits Mais ne soyez pas surpris si l'équipe de base de R n'accepte pas des fonctionnalités totalement nouvelles, même si elles sont accompagnées de code.

Les raisons de cette position ont été discutées auparavant ; même si vous fournissez du code implémentant la nouvelle fonctionnalité X pour l'inclure dans R, vous transférez la charge de la maintenance à l'équipe principale de R et ces personnes ont des ressources et un temps limités pour le faire. L'équipe centrale de R développe effectivement la base de R pour ses propres intérêts/recherches/besoins.

Comme les paquets R sont presque des citoyens de première classe, il y a peu de raisons de demander au noyau R d'implémenter ou d'inclure votre code pour la fonctionnalité X. Donc, comme d'autres l'ont dit, implémentez vos idées de fonctionnalités dans votre propre paquet. o les contribuer à un autre paquet qui fournit déjà le code lié à votre nouvelle fonctionnalité X.

Même des paquets incroyablement utiles et largement utilisés, par exemple table.de.données ne sont pas susceptibles d'être intégrés dans la base R à court ou moyen terme, car ils augmentent la complexité de la base de code, représentent une charge de maintenance pour l'équipe centrale de R et/ou ne remplacent pas le code existant ; table.de.données fournit une extension de type cadre de données qui est incroyablement rapide et mieux adaptée aux grands ensembles de données et aux "requêtes" sur ces données. Il n'est cependant pas compatible avec le cadre de données de R, car il utilise des conventions différentes. Il fonctionne bien en tant que package et peut continuer à le faire en tant que tel sans avoir besoin d'être sur R.

Ce qui précède décrit la situation telle que je la vois pour les nouvelles fonctionnalités. Pour les rapports de bogue, déposez un rapport de bogue ! Pensez ensuite à poursuivre la discussion sur R-Devel en citant l'ID du rapport de bogue. Les correctifs fournis à l'appui de votre rapport de bogue faciliteront la correction des bogues ou l'ajout de nouvelles fonctionnalités/améliorations. Le correctif doit inclure à la fois les sources R qui doivent être modifiées et un correctif pour toute documentation qui doit être modifiée en conséquence. Le correctif doit être comparé à l'arbre SVN qui se trouve à l'adresse suivante le serveur SVN de R . Comme @BenBolker le mentionne dans les commentaires, les rapports de bogues sont mieux classés dans le site Web de rapport de bogues de R. Toute discussion sur le bogue sur R-Devel doit comporter un lien vers le rapport de bogue. De cette façon, les bogues ne tombent pas dans les failles et ne sont pas oubliés.

0 votes

Merci pour cet aperçu ! L'aspect "complexité accrue combinée à des ressources limitées" est logique.

6 votes

+1 La question de la charge de la maintenance est très importante. Peu de gens aiment maintenir leur propre code, et encore moins un code dont ils ont hérité. D'un autre côté, une simplification du code qui le rend plus facile à maintenir et à étendre peut être très appréciée. D'après mon expérience (pas avec R, mais avec d'autres logiciels), cela est généralement obtenu par une refactorisation très intelligente ou une abstraction créative de la fonctionnalité. De même, des cas de test ou des exemples utiles peuvent être les bienvenus : ils réduisent indirectement l'effort de maintenance et les distractions associées.

4 votes

Belle réponse, mais je ne suis pas tout à fait d'accord avec le dernier paragraphe. Cela me frustre énormément que l'on décourage les gens d'utiliser le bug tracker et qu'ils préfèrent envoyer les rapports de bogues à r-devel où ils peuvent facilement passer entre les mailles du filet et ne peuvent pas être recherchés facilement. (C'est surtout une plainte contre R-core pour leur découragement efficace en hurlant sur les gens qui postent des non-bugs de bonne foi, pas contre vous).

17voto

BondedDust Points 105234

La méthode habituelle consiste à écrire un paquet, et à le mettre sur CRAN. (Toutes les annonces envoyées à la liste des paquets sont copiées dans rhelp). Ensuite, la démonstration de son utilisation productive sur rhelp (ou peut-être SO) le fera remarquer. Je pense ici aux efforts déployés au fil des ans par Hadley Wickham, Dirk Eddelbuettel, Terry Therneau, Gabor Grothendieck, Frank Harrell et Matthew Dowle, pour citer les six premiers contributeurs qui me viennent à l'esprit et qui ont rendu mes efforts en matière de R plus productifs. En fait, alors que j'écrivais cette liste, elle n'a cessé de s'allonger et je m'excuse auprès de plusieurs autres personnes qui ont apporté des contributions que j'utilise souvent.

8 votes

David, tout d'abord, je vous tire mon chapeau pour votre présence continue sur r-help. Vous faites un travail d'orfèvre. C'est très apprécié.

0 votes

Ici ! Je suis constamment étonné par votre capacité à traiter les questions de R-help, David.

2 votes

Merci les gars ... J'essaie toujours d'apprendre ce que sont toutes ces échelles sur ma règle à calcul. Surtout cette échelle LL3.

15voto

Richie Cotton Points 35365

À useR cette année, Brian Ripley a raconté une anecdote qui explique la position de l'équipe R-core. Il a dit qu'il avait accepté un patch de deux lignes pour une fonction d'un programmeur R très respecté ( John Chambers si je me souviens bien). Les deux lignes de code contenaient trois bogues ( !), qu'il a ensuite dû corriger. Depuis lors, la position par défaut de R-core est de refuser les demandes de fonctionnalités pour R-base, même celles dont le code est fourni. (Les demandes de correction de bogues sont acceptables, tant que vous avez vérifié qu'il s'agit bien d'un bogue. Utilisez le Système de suivi des bogues R pour cela.)

S'il n'est pas impossible d'intégrer quelque chose dans R-base, il est presque toujours beaucoup plus facile (p < 1e-6) de créer soi-même un paquetage ou de l'ajouter à un paquetage existant.

3 votes

John Chambers n'est-il pas un noyau R membre ? ? (Ne pouvait-il pas simplement vérifier son code bogué dans le serveur SVN lui-même ?)

0 votes

@Ben : Il l'est certainement maintenant. Soit c'était il y a longtemps, soit je me suis mal souvenu du nom. Mon cerveau m'assure que le reste de l'anecdote est fidèlement rappelé.

0 votes

Il a été pour années .

3voto

jthetzel Points 2349

Je suis également intéressé par cette question. Ma première pensée est "très prudemment". On peut soumettre un rapport de bogue "wishlist" à l'adresse suivante https://bugs.r-project.org/bugzilla3/ en veillant à inclure "Wishlist" au début de la ligne d'objet. Sinon, j'envisagerais R-help pour des demandes plus générales de fonctionnalités, et R-devel pour des suggestions plus spécifiques, y compris du code ou des correctifs. Cependant, j'aimerais savoir ce que les utilisateurs plus expérimentés ont à dire.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X