Bug tracking & triaging proposal

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