Dear Valerie, When I talked about maintenance status I thought something on the line of this badges at http://www.repostatus.org/ : Maybe only the last three status are relevant to Bioconductor :
- Active: The project has reached a stable, usable state and is being actively developed. - Inactive: The project has reached a stable, usable state but is no longer being actively developed; support/maintenance will be provided as time allows. - Unsupported: The project has reached a stable, usable state but the author(s) have ceased all work on it. A new maintainer may be desired. Tweaking a bit the description it could be used to classify the support given to a package. Given these categories and the information there is in the repositories and in support site I suggest the following: Giving the Active badge when there are commits (not done by the Bioconductor project) in 6 months. Excluding the Bioconductor team is done to prevent having packages as Active which are not, because the only change is the version number or minor changes done by the Bioconductor team (Also, is not the responsibility of the Bioconductor team to maintain the packages, is it?). Or when at least once every six months the package maintainer answers or comments a question (tagged with the package tag) in the support site if there is any.As an example edgeR would be Active, it has commits from the maintainers in the last 6 months. If a question tagged with a package tag is unanswered and the maintainer hasn't answered/commented in the last 6 months or there isn't any commit in the last 6 months the package (by the maintainer or other than the Bioconductor team) could be set to Inactive. CorMut would be Inactive and close to the Unsupported status. If there is any unanswered question tagged with a package tag and the maintainer hasn't answered/commented in the last year and there isn't any commit from the maintainer in the last 2 years, I would give the Unsupported tag to that package. topGO would be in that category. Once Unsupported status is reached the team could try to contact the maintainer to let him/her know that the maintainer position could be taken by somebody else willing to. Of course, if he/she makes commits or answers/comment questions in the support site to make the status of the package back to Active he/she could keep the maintainer status. This system could be along with the current End of Life Policy, or not, but gives an opportunity to the community of users to maintain a package they deem useful. It is a bit more complex but would guide much better on what packages are well supported and not only used. and those used but not supported could be saved from Deprecation. HTH, Lluís On 18 January 2017 at 17:52, Obenchain, Valerie < valerie.obench...@roswellpark.org> wrote: > Hi, > > On 01/14/2017 03:01 AM, Lluís Revilla wrote: > > Dear Valerie and all, > > > > If I understood the page you kindly linked correctly, a package is > deprecated: > > 1) When it fails to build and check (unless it is fixed). > > 2) When the maintainer asks for it. > > 3) If the maintainer is unresponsive (I assume when a mail is not > > delivered) and(/or?) doesn't answers questions about the package (How > > is this tracked? Which is the threshold for unanswered questions, 1 > > year? ) > We contact maintainers when a package fails on the build system. There > isn't a set rule on the number of times contacted with no response > because there are so many exceptions, e.g., transferred maintainer ship, > away from email due to travel, etc. I'd say the average number of > contacts is 3 before getting the final 2 week notice. > > > > > In some packages, it seems the maintainers receive the mails, and the > > packages build and past the daily checks of Bioconductor, but there > > are bugs and issues with those packages that are left unanswered and > > unsolved in support.bioconductor.org. Those packages that are still > > functional and used but don't receive maintenance are then kept ? How > > should the community help to solve those issues? > A primary motivation for implementing badges on the landing pages was to > provide the "maintenance status" you mention below. The badge stats give > an idea of how active the maintainer is (posts, commits, coverage) as > well as the level of use by others (downloads). The 'posts' badge shows > support site activity over that past 6 months in terms of 4 fields: > tagged questions / average answers per question / average comments per > question / accepted answers. > > The CorMut package has no tagged questions: > > http://www.bioconductor.org/packages/3.5/bioc/html/CorMut.html > > If Guangchuang had asked questions on the support site instead of > posting comments in a gist there would be a number of tagged questions > with no answers. This would give other users some data to go on - an > unresponsive maintainer of a package with no unit tests. In contrast, a > package like edgeR has an average of 1 answer and 3 comments for every > question asked: > > http://www.bioconductor.org/packages/3.5/bioc/html/edgeR.html > > We don't have a system in place to remove packages from the repo based > on unanswered questions or bug reports. Ideally the combination of badge > stats and input from others on the support site (i.e., 'what package > would you recommend for ...') is sufficient to get direction on actively > maintained and well-thought-of packages. > > If there are suggestions for improving the badges please let us know. > There may also be parts of the package review process that could be > improved such as requiring unit tests instead of suggesting them. But > again, having unit tests does not guarantee that all (or the most > important) aspects of the package are tested. > > Valerie > > > Thanks, > > > > Lluís > > > > On 6 January 2017 at 18:56, Obenchain, Valerie > > <valerie.obench...@roswellpark.org> wrote: > >> On 01/04/2017 07:53 AM, Lluís Revilla wrote: > >>> Dear Guangchuang and all, > >>> > >>> Quality of the packages has been a preoccupation of the project from > >>> the beginning (see > >>> https://stat.ethz.ch/pipermail/bioc-devel/2014-May/005810.html for > >>> more references and other discussions about bug reports.) Despite not > >>> being in a goal of the project, it is necessary to do a reproducible > >>> research, which it is a goal: "To further scientific understanding by > >>> producing high-quality documentation and reproducible research.". > >>> Although it seems that this discussion appears periodically > >>> Bioconductor I don't know any solution in the project. > >>> > >>> I have never submitted a package to Bioconductor or CRAN, and I am > >>> quite new to R (and is my first mail to the list), but one thing that > >>> I keep thinking (before publishing a package) is the maintainability > >>> of it. I don't know how much time/desires will I have to dedicate to a > >>> package (if it is accepted) in the future, but at the same time I want > >>> to make useful code to be used in further research beyond my own > >>> project. > >>> > >>> However the Bioconductor core team may be already too busy to deal > >>> with the issues of all packages. Maybe it would be better to bring > >>> CRAN's policy to orphan packages (see: > >>> https://cran.r-project.org/src/contrib/Orphaned/README): > >> Bioconductor does have a system for dealing with orphaned packages > >> called End of Life: > >> > >> http://www.bioconductor.org/developers/package-end-of-life/ > >> > >> Deprecated packages have a strikethrough the name on the build reports, > >> e.g., the saps package, > >> > >> http://www.bioconductor.org/checkResults/devel/bioc-LATEST/ > >> > >> > >> Valerie > >> > >>> "Possible reasons for orphanizing a package: > >>> > >>> 1) The current maintainer actively wants to orphanize the package, > >>> e.g., due to no longer having time or interest to act as package > >>> maintainer. > >>> > >>> 2) Emails sent to the current maintainer by the CRAN admins bounced, or > >>> were not answered for longer periods of time. > >>> " > >>> Example of an orhpan package is clusterRepro. > >>> > >>> To orphanize a package the current maintainer could post it here on > >>> the devel list and ask for a maintainer on the support site, and it is > >>> his/her decision to whom is passed the responsibility. > >>> Otherwise, maybe the limit of time without answering mails/posts in > >>> support could be 3 months/6 months. (I don't know the CRAN decision > >>> when not answering mails) > >>> > >>> Once the orphaned status is reached maybe however who wants could send > >>> patches or take the maintenance of the package for another 3 months or > >>> more. > >>> > >>> This status would not make bugs easier to fix or control, but could > >>> mark that a package is not in the best maintenance status. > >>> > >>> Hope this helps, > >>> > >>> Lluís > >>> > >>> > >>> ---- > >>> Date: Wed, 4 Jan 2017 15:38:53 +0800 > >>> From: "Yu, Guangchuang" <g...@connect.hku.hk> > >>> To: bioc-devel <bioc-devel@r-project.org> > >>> Subject: [Bioc-devel] report package issue to Bioconductor > >>> Message-ID: > >>> <CAEF2yOdEQ9LOA3nFbLBvNddtLTKMZ-YiVkCf7UMJRRpfQP7Lmw@mail. > gmail.com> > >>> Content-Type: text/plain; charset="UTF-8" > >>> > >>> Dear all, > >>> > >>> Some packages never updated after they publish a paper, and they just > >>> ignore bug report. > >>> > >>> I think we need somewhere, maybe on github, to post code review and > >>> Bioconductor core team can take action if maintainer fail to fix issue. > >>> > >>> Here is a quick look of the CorMut package: > >>> https://gist.github.com/GuangchuangYu/91b3396c7e49ab42c565a9cda3c35e18 > . > >>> > >>> There should be more issues than I can found with quick look of the > source > >>> code. > >>> > >>> Best wishes, > >>> Guangchuang > >>> ? > >>> -- > >>> --~--~---------~--~----~------------~-------~--~----~ > >>> Guangchuang Yu, PhD Candidate > >>> State Key Laboratory of Emerging Infectious Diseases > >>> School of Public Health > >>> The University of Hong Kong > >>> Hong Kong SAR, China > >>> www: https://guangchuangyu.github.io > >>> -~----------~----~----~----~------~----~------~--~--- > >>> > >>> _______________________________________________ > >>> Bioc-devel@r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel > >> > >> > >> > >> This email message may contain legally privileged and/or confidential > information. If you are not the intended recipient(s), or the employee or > agent responsible for the delivery of this message to the intended > recipient(s), you are hereby notified that any disclosure, copying, > distribution, or use of this email message is prohibited. If you have > received this message in error, please notify the sender immediately by > e-mail and delete this email message from your computer. Thank you. > > > > > This email message may contain legally privileged and/or confidential > information. If you are not the intended recipient(s), or the employee or > agent responsible for the delivery of this message to the intended > recipient(s), you are hereby notified that any disclosure, copying, > distribution, or use of this email message is prohibited. If you have > received this message in error, please notify the sender immediately by > e-mail and delete this email message from your computer. Thank you. > [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
