[Bioc-devel] how can I contribute to the success of great packages?

[Martin Morgan]

On 10/20/2017 07:00 PM, Dario Strbenac wrote:
> Hello,
> 
> I noticed that October 24 is "Deadline for packages passing ‘‘R CMD build’’ and ‘‘R CMD check’’ without errors or warnings." and "Identify packages to be ‘deprecated’ in the new devel, Bioconductor 3.7." and "... or those with errors and unresponsive maintainers." If the Release Schedule document at https://www.bioconductor.org/developers/release-schedule/ is accurate, then there is some uncertainty as to whether Gviz would fall into this category. That deadline is only 4 days away.
> 

Take a look at the build report for devel

   http://bioconductor.org/checkResults/3.6/bioc-LATEST/

and note that there are >150 packages with WARNINGS (and that Friday was 
another bad day for Windows!); many of the packages maintained by the 
core have warnings similar to the one that concerns you -- missing and 
largely redundant documentation entries.

Look also at the list of packages removed from Bioconductor

   http://bioconductor.org/about/removed-packages/

to get a sense for how often packages are removed.

Look at the package download stats

   http://bioconductor.org/packages/stats/

and note the relative position of packages (and removed packages, if 
removed recently) to get a sense of how often heavily used packages are 
removed.

See the approach to package end-of-life that we try to follow, when possible

   http://bioconductor.org/developers/package-end-of-life/

to get a sense of how we try to limit the consequences of package 
deprecation for both users and developers. Developers have 6 months 
warning, e.g,. to step forward and take over a central package, or to 
identify other solutions; users have a full 12 months before seeing the 
consequences of package deprecation.

The core team reaches out to maintainers multiple times before 
end-of-life starts, to make sure they are aware of the situation.

The core team tries to triage support site questions; if they are 
important enough [e.g., a package is broken because of changes in a 
dependent package] we send email to the maintainer.

We try to 'carry a big stick' to motivate developers to stay on top of 
their package, but exercise sensible discretion in light of the 
realities of software development and user needs.

>> Part of the joy of open-source software is participating in support and maintenance -- why not tackle unanswered questions with your own best effort?
> 
> Indeed, this is an advantage of open-source software, but if on the support website, questions have been unanswered in the past 3 months, would a pull request have any effect or also be ignored?

It's easy to find questions that have a green 'unanswered' field for 
packages from all walks of Bioconductor life; it would be great if all 
maintainers were named Lun, or that Lun answered all types of questions, 
but that's just not realistic.

A pull request means that you know the answer, so posting an answer to 
the support site would be helpful to the individual posting the 
question, and to others with similar problems, even if the answer is 
'this is the problem and you'll need to wait for the maintainer to 
respond', and even if the pull request were ignored by the maintainer.

When bioc help was a mailing list, a common practice would be to respond 
to the list and cc the maintainer, so the personal email rose above the 
day-to-day traffic; grabbing the link to your support site response and 
sending a brief email to maintainer("some package") has similar effect.

It is humbling to try and answer a question. You realize how challenging 
it is to understand and replicate the basic problem, and how much time 
it takes to provide a reasonably sensible answer to even a well-posed 
question with a simple answer; I doubt that even the shortest of my 
replies take less than 15 minutes to compose.

Documentation shortcomings are often the simplest to fix and an easy way 
to participate in open-source development.

If you'd like to continue this discussion in general terms, then start a 
thread with a more sensible title and of a general nature.

Gviz is a great package in no danger of being abandoned, by the 
maintainer or by the Bioconductor community.

Martin

> 
> --------------------------------------
> Dario Strbenac
> University of Sydney
> Camperdown NSW 2050
> Australia
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> 


This email message may contain legally privileged and/or...{{dropped:2}}