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."
The problem is that both Trac and the Github tracker are inadequate tools for managing a big project like Plone with lots of facets. Both tool lack supported for structured metadata, dependency management etc.
Expecting some beatings but the project really needs a more powerfull and professional solution - look at JIRA which provides free licenses for open-source projects with a good support and useful integrations for Github or whatever.. Trac and thr Github tracker are just not approachable from the developers point of view.
And in order to lower the barrier for standard users from posting a bug using a complex system like JIRA it would be easy to create a custom form for anonymous users with some field and some simple metadata options. Such a ticket would be created in Jira and the committer group could then add or edit the related metadata....this is some work but doable. We used this approach for the Europython helpdesk where users can even submit requests by email. We managed roughly 1000 requests so far over the last few months. Managing the helpdesk with a toy tool like Trac would have never worked.
There are bigger projects on github than Plone. I think simplicity on issue tracking is more important than extensive metadata handling. The tagging feature on github would solve most categorization needs anyway.
And honestly, JIRA might be the most complete issue and project management solution out there, but the user interface is crap and it's way too unresponsive. We're using it in a current project and I dislike it.
The UI is cluttered with 100reds of fields, if you forget to fill some metadata or press some buttons (like "Fix version/s" or "Start progress") the logged work isn't included in reports or something else fails.
It's so unresponsive: I always have to wait for many seconds to a few minutes until something happens.
Nonsense for both points. If properly configured you can adjust JIRA as needed with a simple UI to a complex UI - dependent on the project and user requirements. We are using JIRA both self-hosted and as cloud solution hosted by Atlassian. The performance is truly good enough - never seen longer waiting times...get decent hardware.
Tagging for such a big project will end up in a mess. Metadata and proper classification is to some degree for a big project. I am not a friend of MongoDB but they did the bug tracking right:
It's a project with similar complexity and size...please make a big step and don't try to replace the tinkered toy Trac with another tool in the same league.
We used to have a self-hosted instance of JIRA running on projects.plone.org.
It was OK, but there were LDAP integration issues that meant you used to
get logged out all the time. I'm sure those are resolvable, though, and
JIRA has gotten a lot better recently.
It is a lot of work to set up Jira to be both simple and responsive. I have both great and horrible experiences with using Jira, but from what I understand, the Jira where I had a great experience there was a lot of work put in to make it great. Also, as Martin said I think newer Jiras are better and faster.
I had the same experience with the Atlassian hosted jira.
If we can get away with something simpler like using github issues, and if possible with a custom bug report form using the API that allows anonymous submissions I think we would be a long way there.
And sanity for people who help fix bugs on multiple repos, both in the plone namespace and the collective namespace.
We don't hire people to deal with our bugs, we rely on volunteers. Maybe Jira can be mangled to look less intimidating than the Mongodb instance, but it's Yet Another Tool To Learn. And not the easiest. There's multi-day courses in using Jira on offer (yep, I followed one once ;-))
A lot of our most active people have started out by first writing their own add-ons, in the collective usually. Those will have a github issue tracker these days. If for bugmanagement on the plone.xxx namespace we'll use somethiing else, and still use github for collective.xxx packages, that's going to be a pretty schizo experience.
So, for me a preferred solution should try to have these:
Works for both collective.xxx and plone.xxx packages
Is usable for 'part-time' product authors without studying for half a day (and possibly having to repeat that everytime they have time to work on bugs in their package, or try to help out in other people's packages)
is not maintained or written by us, as we have a historically bad track record of maintaining bugtrackers
is as friendly to use for end-users as possible
if Jira can be mangled to do that, with also actual volunteers saying they'll do that and not just assert the theoretical possiblity, I'm just fine. But personally I'll gladly give up highly advanced features for a solution that will get more traction because it's easier to use and fits in with people's current habits.
my 2c (dollarcents today, back to real money this afternoon)
I am not advocating JIRA but I am advocating a reasonable solution that adds a reasonable functionality for a project of the size of Plone. By "reasonable" I mean: find and filter stuff easily and this requires in my eyes reasonable metadata. I agree with the "ease of use" and "barrier of entry" requirements regarding people contributing to Plone in terms of bug reports. And this can be accomplished by JIRA easily. And I still consider tools like Trac or Github tracker as inadequate for a project of this complexity. But now I shut up, you got my point (hopefully :-))
BTW: not all replies I have in my inbox of this discussion are also visible in the webinterface, sigh.
But really great to see, so many get involved with this topic. The question-mark always in my mind though is: Why don't we do it with Plone? Because - you know - "we can", Plone can! It's outstanding permission-management could be the very trump, compared to the other tools. And we can take care and decide to make it as simple as possible and as complex as necessary then, avoiding to to be prone to that buggyness a lot of the other tools suffer off.
Also important to me: Have it under our hood (legacy-issue), like others mentioned, too, by now.
Apart from that, I'd like to figure out, how we can collect all the given opinions, arguments and furthermore aspects in a more structured and compact way than a chatty discussion, in order to find a consense for the wanted requirements, any ideas someone? Or maybe not necessary?
And FWIW, a client of mine started to write a ticketsystem as a Plone-add-on and is willing to publish that under GPL, which should happen 'soon' (the next weeks), the next iteration is in queue, too. As there are probably some more Plone-add-ons trying to accomplish this, it might be possible, to connect these projects, if the goals (reqs) are the same or parts can be used of it ("don't reinvent the wheel").
I'm actually a Fan of Products.POI. It's just missing the Web2.0 feeling, which make it more fun to work with and more reponsive. And a trello like view. And a Dexterity upgrade to allow behaviors for trackers and issues. And a budget to bring it to that point (but it's only a manageable amount of work).
On the other hand, the tight integration of code hosting, inline comments, pull requests and issue tracking on Github, Bitbucket, Gitlab and as I recently learned RhodeCode is a killer feature of these code hosting platforms. Producds.POI will never be able to compete with that, I guess.
"Those who don't learn from history are doomed to repeat it"
(any random quote on the interwebz, mostly attributed to Edmund Burke)
I think it has been proven with both POI and PloneCollectorNG we don't do issue tracker software well. It's not our core business, so nobody is interested enough to maintain them.
I also think, looking at this (great! hope more people still chime in!) discussion, it's virtually impossible to find the One Tool That Suits All, since we have a diverse group of people, each with their own preferences and tastes. That's why I still think a light-weight solution is better than a very heavy one, and one that has large traction.
Github issues does lack features, but that of course means people are scratching itches, and are coming up with ways to counter that. From https://huboard.com to https://overv.io/ to https://waffle.io/ to datahero, there's plenty of tools to help in Kanban, reporting, sorting etcetera. I'm sure there's more around, these are just a few I've played with.
The key issue is that these tools all leave the issues in github, they just rely on some sane definition of milestones and tags. That's definitely a Good Thing (TM).
That means that plone/documentation can use another tool than plone/plone.app.dexterity, which is probably fitting. Hell, it even means I can use a different tool than you (*for varying values of you *) while working on the same repository
That doesn't make it ideal; but it does allow more freedom to suit workflows from the code-ninjas to the doc-wranglers, and from the "I eat multi-adapters for breakfast" to the "during my lunchbreak I'll help out" types.
I think it has been proven with both POI and PloneCollectorNG we don't do
issue tracker software well. It's not our core business,
Someone just needs to start a business selling this kind of service based on
Plone :-]
I also think, looking at this (great! hope more people still chime in!)
discussion, it's virtually impossible to find the One Tool That Suits All,
[...]
The key issue is that these tools all leave the issues in github,
Regarding the unlikelihood of One Perfect Tool, and the issue of siloed issues
at github, I thought I'd just mention the idea of distributed issue trackers.
The issues are stored in the DVCS. Here's one that even syncs with other
trackers, including github issues: http://syncwith.us/sd/
I replied by email and Discourse added a blank message.
I edited the blank message and got the error: "Sorry, new users can only put 2 links in a post."
So maybe that caused the mail-in to fail.
I might be naive, it's just from my point of view, Plone has all these great features (workflows, contentrules, relations, discussions, collections, etc), which just need to be wired together via non-intrusive xml-configs e.g. - not programmed from scratch - to represent what a basic ticketsystem needs.
If done with these features, maintaining shouldn't be a lot of work. But that very much depends on our reqs, which we will never agree upon to
You got some nice points here. I'd go along with GitHub also, as ease of use is fairly given.
BTW it allows translators (also non-techies) to commit strings via GitHub's webinterface in a very comfy way, no other hurdles in between, as it used to be +1
And it'll be not another tool ("keep the stack down low").
[1]: https://datahero.com/blog/2013/08/13/managing-github-projects-with-datahero/
(hopefully :-))
+1