In a similar vein to Yihui's suggestion, could we encourage developers to use the "BugReports" field of the DESCRIPTION file, and pull that URL out and link it on the main page of a project? This could be a <mailto> link if the developer wants email to go directly to them, or point to the issues page of a github repo, or any other bug tracker that the developer wants to use.
My 2 cents. -Robert Robert M Flight, PhD Bioinformatics PostDoctoral Scholar Twitter: @rmflight <https://twitter.com/rmflight> Web: rmflight.github.io The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" (I found it!) but "That's funny ..." - Isaac Asimov On Sun, Jun 8, 2014 at 9:37 AM, Keith Hughitt <keith.hugh...@gmail.com> wrote: > I agree that trying to incorporate all bioconductor projects into a > single bug tracker could be messy. Although Github could handle this > (e.g. using project-specific issue labels), it might still become > overwhelming. > > Instead, perhaps it would be best just to spend some time to draft > some "suggested" conventions for dealing with issues, and follow those > conventions for the core package. > > Then, similar to CRAN, a "issues" link could be included on each > bioconductor project page to direct people to the relevant issue > tracker, if one has been setup. > > This would make it very straight-forward for users to find where to > report bugs and feature-requests for any given project. By keeping > things as "guidelines" or "suggestions", people can still choose not > to maintain a dedicated issue tracker if they are really opposed to > it, or to choose an alternative bug tracking system aside from the > recommended one if they have a strong preference -- the link will > still be in the same place though so the user can at least find it > just as easily. > > Finally, once some conventions have been agreed on, the pages on the > (1) setting up an issue tracker and (2) reporting a a bug or feature > request could be fleshed out a bit more to make it very easy for both > users and devs to orient themselves. For the devs, this could include > instructions for setting up the recommended issue tracker, and how to > populate the relevant field on the bioconductor project. For the > users, this could include a more detailed description of where to > report bugs, what information to include, etc. > > Keith<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, > May 27, 2014 at 11:25 AM, Cook, Malcolm <span dir="ltr"><<a > href="mailto:m...@stowers.org"; > target="_blank">m...@stowers.org</a>></span> wrote:<br><blockquote > class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc > solid;padding-left:1ex"><div class="">>> Martin,<br> > >><br> > >> I'm sure you're watching this thread.....<br> > >><br> > >> Can we take it as some "feedback from other developers" > that you requested way back in <a > href="https://stat.ethz.ch/pipermail/bioc-"; > target="_blank">https://stat.ethz.ch/<wbr>pipermail/bioc-</a><br> > >devel/2011-October/002854.<wbr>html when I wished for > similar....<br> > >><br> > ><br> > >I don't really have anything constructive to add to the > thread.<br> > <br> > </div>Actually your history lesson is valuable to the discussion. > Thanks!<br> > <br> > Honestly, I really don't have a great problem with things as they > stand. I get plenty of attention to _my_ questions/observations > in a timely and informative manner....<br> > <br> > I do think that the BioC project hosting a tracking system might > eliminate a hurdle for some developers, but the trade-off is hard for > me to assess.<br> > <br> > Cheers,<br> > Malcolm<br> > <div class="HOEnZb"><div class="h5"><br> > ><br> > > From a project perspective it would be great to have a > centralized bug tracking<br> > >facility; there are many bugs, they are poorly tracked even > by the most diligent<br> > >of us, and it would benefit users and developers alike to > have a convenient way<br> > >to view our laundry.<br> > ><br> > >Most off-the-shelf bug tracking systems are not designed to > work under the<br> > >'federated' (I guess that's not the right technical > description) model of<br> > >Bioconductor where there are a large number of individual > projects, so<br> > >implementing a workable solution requires quite a lot of > effort and / or ongoing<br> > >management. As we've seen with the rise of github and its > use by even key<br> > >contributors to the project, it is very difficult to impose > a central system on<br> > >our developers, even for such a key aspect as code > management. Users are<br> > >similarly very difficult beasts to train, so their > structured participation<br> > >would be inconsistent. While on the one hand bug tracking > might seem like a<br> > >no-brainer for an experienced developer, it adds another > hurdle (along with<br> > >mastering version control, the R package system, vignettes, > ...) to potentially<br> > >discourage more novice developers who nonetheless are making > valuable<br> > >contributions to the project.<br> > ><br> > >In response to the earlier thread, the developers in Seattle > did use an<br> > >Atlassian / Jira based internal bug tracking system and > pursued it for about a<br> > >year, with the goal being to make it available generally if > it seemed like it<br> > >would 'fly'. There was varied enthusiasm and participation > within the group.<br> > >Perhaps I was less diligent than others; I found that my > bugs were either<br> > >addressed before they got into the tracker, or entered the > tracker as a place to<br> > >die. The bugs would die because they weren't of high enough > importance or<br> > >clearly enough articulated to act on when they arose, and > with the passage of<br> > >time their perceived importance and relevance declined. > There were some<br> > >individual successes, where tracking a bug helped to > coordinate input from<br> > >different people and to collate insights and proposed > solutions into a focused<br> > >discussion, and where the bug tracker served as a kind of > long-term memory bank<br> > >for issues that did eventually get addressed. Use of the > tracker declined with<br> > >time, presenting an increasingly inaccurate representation > of activity in the<br> > >project.<br> > ><br> > >Martin<br> > ><br> > ><br> > >> In any case,<br> > >><br> > >> +1,<br> > >><br> > >> Malcolm<br> > >><br> > >> >-----Original Message-----<br> > >> >From: <a > href="mailto:bioc-devel-boun...@r-project.org > ">bioc-devel-bounces@r-project.<wbr>org</a> > [mailto:<a href="mailto:bioc-devel-boun...@r-project.org > ">bioc-devel-bounces@r-<wbr>project.org</a>] > On Behalf Of Keith Hughitt<br> > >> >Sent: Friday, May 23, 2014 12:53 PM<br> > >> >To: Nicolas Delhomme<br> > >> >Cc: <a > href="mailto:bioc-devel@r-project.org";>bioc-devel@r-project.org</a><br> > >> >Subject: Re: [Bioc-devel] Bug tracker for > Bioconductor?<br> > >> ><br> > >> >Hi Nico,<br> > >> ><br> > >> >It's a shame that the effort did not gain > more traction in 2004. I wonder<br> > >> >if things would look differently now as the > community has grown<br> > >> >significantly larger?<br> > >> ><br> > >> >It does seem like there are a relatively > small number of bug-related<br> > >> >questions on the mailing lists. I wonder > though if this could be in part<br> > >> >because some people may be hesitant to ask > their questions on such a large<br> > >> >list, and instead end up either forgoing the > question or contacting the<br> > >> >software authors directly?<br> > >> ><br> > >> >Also, even if there is only a trickle of bug > and feature-request related<br> > >> >posts to the mailing list across time, > without any way to keep track of how<br> > >> >many of those issues are open/unresolved, > it's hard to gauge whether the<br> > >> >project really is low-maintenance, or if > there are actually a large number<br> > >> >of issues that have just been unanswered or > forgotten.<br> > >> ><br> > >> >There would definitely be a burden > associated with setting up a more<br> > >> >sophisticated system for dealing with bugs. > I am just not convinced that<br> > >> >the burden would be too great, or that it is > not worth taking on :)<br> > >> ><br> > >> >Cheers,<br> > >> >Keith<br> > >> ><br> > >> ><br> > >> >On Tue, May 20, 2014 at 10:33 AM, Nicolas > Delhomme<br> > >> ><<a > href="mailto:nicolas.delho...@umu.se";>nicolas.delho...@umu.se > </a>><wbr>wrote:<br> > >> ><br> > >> >> Hej Keith!<br> > >> >><br> > >> >> I agree that this would be useful. For > having been very close to the 2004<br> > >> >> attempt - a then colleague of mine set > up a solution similar to what you<br> > >> >> describe - I can tell you that the main > reason for it dying out was that<br> > >> >> despite advertising it, it never got > widely used. I donât know what the<br> > >> >> reasons for that really were, but from > experience I know that many fellow<br> > >> >> bioinformaticians find such tools more > time-consuming than handling bug<br> > >> >> tracking through emails. And after all > very few packages require frequent<br> > >> >> support, as can be devised from > questions to the mailing list, so I do<br> > >> >> understand their point.<br> > >> >><br> > >> >> Cheers,<br> > >> >><br> > >> >> Nico<br> > >> >><br> > >> >> > > ------------------------------<wbr>------------------------------<wbr>---<br> > >> >> Nicolas Delhomme<br> > >> >><br> > >> >> The Street Lab<br> > >> >> Department of Plant Physiology<br> > >> >> UmeÃ¥ Plant Science Center<br> > >> >><br> > >> >> Tel: <a > href="tel:%2B46%2090%20786%205478" value="+46907865478">+46 90 786 > 5478</a><br> > >> >> Email: <a > href="mailto:nicolas.delho...@plantphys.umu.se > ">nicolas.delhomme@plantphys.<wbr>umu.se</a><br> > >> >> SLU - UmeÃ¥ universitet<br> > >> >> UmeÃ¥ S-901 87 Sweden<br> > >> >> > > ------------------------------<wbr>------------------------------<wbr>---<br> > >> >><br> > >> >> On 20 May 2014, at 15:04, Keith Hughitt > <<a href="mailto:keith.hugh...@gmail.com";>keith.hugh...@gmail.com > </a>> > wrote:<br> > >> >><br> > >> >> > Hello all,<br> > >> >> ><br> > >> >> > I was wondering if there had been > any progress towards adopting a bug<br> > >> >> > tracking system for Bioconductor?<br> > >> >> ><br> > >> >> > It has been discussed at least a > couple times in the past, e.g.:<br> > >> >> ><br> > >> >> > - <a > href="https://stat.ethz.ch/pipermail/bioc-devel/2011-October/002844.html"; > target="_blank">https://stat.ethz.ch/ > <wbr>pipermail/bioc-devel/2011-<wbr>October/002844.html</a><br> > >> >> > - <a > href="https://stat.ethz.ch/pipermail/bioc-devel/2004-October/000040.html"; > target="_blank">https://stat.ethz.ch/ > <wbr>pipermail/bioc-devel/2004-<wbr>October/000040.html</a><br> > >> >> ><br> > >> >> > But as far as I can tell, no such > system has been set up and the current<br> > >> >> > approach is to report issues to > the mailing list.<br> > >> >> ><br> > >> >> > The main reasons I see for > adopting such a system would be:<br> > >> >> ><br> > >> >> > 1. Centralized location for > reporting and tracking bugs and feature<br> > >> >> > requests; this also makes it more > straight-forward to see if anyone else<br> > >> >> > has already reported a specific > issue.<br> > >> >> ><br> > >> >> > 2. Ability to associate a given > issue with specific a project<br> > >> >> ><br> > >> >> > 3. Ability to assign priorities to > various issues and assign developers<br> > >> >> to<br> > >> >> > work on them.<br> > >> >> ><br> > >> >> > 4. Easy to track changes made to a > given release.<br> > >> >> ><br> > >> >> > 5. Separate usage and development > discussion (mailing list) for<br> > >> >> > issue-related discussion.<br> > >> >> ><br> > >> >> > Something like trac <<a > href="http://trac.edgewall.org/"; > target="_blank">http://trac.edgewall.org/</a>> would be sufficient > to<br> > >> >> > cover all of the above issues, > although something with closer integration<br> > >> >> > to the codebase such as Github > <<a href="https://github.com/"; > target="_blank">https://github.com/</a>> or<br> > >> >> > Bitbucket<<a > href="https://bitbucket.org/"; > target="_blank">https://bitbucket.<wbr>org/</a>>might provide some > additional<br> > >> >> > benefits. Of course, migrating to > a separate<br> > >> >> > VCS not a trivial matter and would > itself merit a separate discussion.<br> > >> >> ><br> > >> >> > A couple examples of issue > trackers working well for R projects:<br> > >> >> ><br> > >> >> > <a > href="https://github.com/hadley/ggplot2/issues"; > target="_blank">https://github.com/hadley/<wbr>ggplot2/issues</a><br> > >> >> > <a > href="https://github.com/yihui/knitr"; > target="_blank">https://github.com/yihui/knitr</a><br> > >> >> ><br> > >> >> > Thank you all for your excellent > work on Bioconductor! It is a really<br> > >> >> > amazing resource.<br> > >> >> ><br> > >> >> > Regards,<br> > >> >> > Keith<br> > >> >> ><br> > >> >> > [[alternative > HTML version deleted]]<br> > >> >> ><br> > >> >> > > ______________________________<wbr>_________________<br> > >> >> > <a > href="mailto:Bioc-devel@r-project.org";>Bioc-devel@r-project.org</a> > mailing list<br> > >> >> > <a > href="https://stat.ethz.ch/mailman/listinfo/bioc-devel"; > target="_blank">https://stat.ethz.ch/mailman/ > <wbr>listinfo/bioc-devel</a><br> > >> >><br> > >> >><br> > >> ><br> > >> > [[alternative HTML version deleted]]<br> > >><br> > ><br> > ><br> > >--<br> > >Computational Biology / Fred Hutchinson Cancer Research > Center<br> > >1100 Fairview Ave. N.<br> > >PO Box 19024 Seattle, WA 98109<br> > ><br> > >Location: Arnold Building M1 B861<br> > >Phone: <a href="tel:%28206%29%20667-2793" > value="+12066672793">(206) 667-2793</a><br> > </div></div></blockquote></div><br></div> > > _______________________________________________ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > [[alternative HTML version deleted]]
_______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
