Re: Bug tracking & triaging proposal

Hello,

First, should i mention that github is not opensource and don't give any
guarantee for our data (Term of services G.14)?
https://help.github.com/articles/github-terms-of-service#g-general-conditions

More motivation:

 1. Growing : it's not a problem of location, neither of technology but
    more of motivation. Find something to motivate moderators. A new
    tool can have a good effect or not.
 2. Spaming : it's also a problem of motivation. We need a team to be
    reactive and who can make evolve the ticketing tool. Did I mention
    that git hub is not opensource then we cannot make it evolve?
 3. It's old : yes, it is. Make a cleanup in trac or elsewhere will be a
    long work.
 4. Github is cool : (NIH) no, it is not. It's a perfectible tool but we
    cannot push for any evolution. It's not opensource and the data are
    not ours.
 5. Separate repository: orphan tickets = new split in the community
 6. Too big too fails: do you really still believe in that?
 7. Anonymous tickets: occasional contributors don't want to show their
    identity, it's not a new fact. I don't give my realname when I fix a
    bug in Joomla.

Find a plan to backup all data in github on Plone Foundation servers
then we can start a discussion.
Do you know about project like rhodecode, OAuth and OpenId?

Devil's Advocate


Le 22/06/2014 16:35, polyester wrote:
>
> Intro: this discussion started as offshoot of the "Installer &
> Approachability" sprint in Oshkosh.
>
> Problem: dev.plone.org is suffering; it is unloved, not the prettiest
> kid on the block, and we have to maintain it. Which we don't.
>
>   * the list of untriaged bugs is growing again, everyone's eye is on
>     github and not on dev.plone.org
>   * spam is growing again in the trac
>   * the trac instance itself is showing cracks in the paintwork in various
>     places; setting multiple categories is b0rked, for instance.
>
> Issue tracking on github is nice, but you'd have to know on which
> package you have to submit bugs, which is impossible for the
> uninitated. Even the cognoscenti may not know whether a bug is in
> plone.superform or plone.app.directives.
>
> An easy, standardized, documented way to submit issues for people who
> don't have intimate knowledge of the project is required.
>
> *Possible way out:*
>
>   * start a separate repository, for instance plone/issue-reporting
>     for incoming tickets (although obviously if you are an insider you
>     should file the issue directly on the correct repo)
>   * although github has no built-in way to tranfer tickets between
>     repos at the moment, there are scripts available to move
>     issues: https://github.com/jotweh/IssueRelocate for example. These
>     can be further embellished to make life easy for the triagers, if
>     necessary.
>
> *Requirements:*
>
>   * a triaging group/team with enough knowledge to relocate them to
>     the correct packages. (To be fair, dev.plone.org also needs more
>     help in there, so that situation hopefully improves by using the
>     environment where more people feel at home and work in regularly.
>     Also, having it on github makes for a nicer metric for displaying
>     bugtriaging kudos at the upcoming plone.org)
>   * A mindmap of where to place issues; basically
>     update https://dev.plone.org/wiki/TriagingBugs. We might need to
>     define or possibly create repos for bug categories that have no
>     special repo themselves (upstream tickets, errors on
>     plone.org/com, a11y tickets, ...). As example, you could just file
>     a11y tickets on Products.CMFPlone, but also in an own repo for
>     clarity since some of these might have to be fixed on multiple
>     packages. Needs thought.
>   * While we're at it, we may want to have an up-to-date list of
>     labels that bug-submitters can attach. Labels should be
>     understandable to end users of Plone, not just for hardcore devs.
>
> *Drawbacks:*
>
>   * People have to have a Github account. On the other hand, that
>     allows them to be notified when something happens with their
>     ticket, and we offload a bit of spam-protection to Github
>   * We need to think what to do about old tickets still left in
>     dev.plone.org
>
> *Overview of bugs:*
>
> Oh, and there is a 'give me a dashboard with all bugs for plone', it's
> just a bit hidden away in the interface. That can be fixed with two
> lines of documentation:
>
>     To get a full overview of all open issues in the Plone
>     organisation on github, go to https://github.com, click on your
>     name on the left (that's actually a dropdown menu), and switch
>     context to Plone. You'll see a dashboard, which has a tab named
>     'issues' on the right.
>
> Paul
>
> PS I also posted at
> https://community.plone.org/t/bug-tracking-triaging-proposal/183 to
> reach another audience
>
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
>
>
> _______________________________________________
> Plone-developers mailing list
> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/plone-developers


-- 
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales



------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft