Migrating to GitHub issues
Categories
(Webtools Graveyard :: Pontoon, task, P3)
Tracking
(Not tracked)
People
(Reporter: mathjazz, Unassigned)
References
Details
Attachments
(1 file)
This is a conversation starter to evaluate the feasibility of using GitHub Issues instead of Bugzilla to track bugs for the Pontoon project.
Why GitHub?
- Already used as a critical tool, users don't need another account, barrier to entry is lower.
- It's easier to use. Input form, issues list and search have simpler UX.
- GitHub Issues are easier to reference from within GitHub (PRs, comments, commits...).
- We'll be able to close issues on commit automatically again (see 1486391).
- We'll be able to move roadmap from unmaintained Mozilla Wiki to GitHub.
Why Bugzilla?
- We don't need to do anything.
- We own it.
- Easier to make dependencies with other Mozilla projects (but we barely use that).
- Has established support for (private) security bugs.
|
||
Comment 1•3 years ago
|
||
On the bugzilla side, there's also:
- needinfo
- within-Pontoon dependencies, when doing things like bigger refactors, features
- priorities, severeties
I've got different UX experience, too. In particular when it comes down to search. But also understanding the issues lists and projects in the projectfluent org.
But that might just me and my thing for semantic data.
|
||
Comment 2•3 years ago
|
||
Some more pros for GitHub:
- They're adding some support for automation via GitHub actions.
- You can easily integrate issues in projects.
Having said that, I find the lack of hierarchy (dependencies) not ideal for a project as large as Pontoon, and the lack of an equivalent of NEEDINFO a blocker.
I can easily find issues I'm assigned to, or pull requests I need to review. But if I look at the ones where I'm mentioned, and are still opened, I end up with 43 issues, and have no way to tell if any of those requires an action from me.
Adding my thoughts to the mix here:
I feel like GitHub has a lower barrier of entry for many newer contributors and having the issues there as part of the repo could encourage more contributions. Also, as Matjaz mentioned, I find the GitHub UX easier to use and feel that others would be more inclined to file issues and interact there.
There are also search capabilities within GitHub that help users find projects and issues that are a good match for them that could expose the project to more contributors. For example www.github.com/topics/good-first-issue returns 295 repos with that label and the user can then filter by language and search through those issues for one that would be a good match (adding Python brings that down to 41).
GitHub Actions potentially opens up possibilities to find a similar way to notify for times when 'more info' is needed from someone. For example an Action can be set to look for a certain label and then when applied it would notify whomever it was set up to notify, once the info needed has been given the label can be removed, and if more info is needed again the label can be re-added thus triggering the Action. This is a bit of conjecture, but I did see that there are Actions in the marketplace set up to notify for labels on Issues, and I found a blog post from someone who set up an Action to email certain people when a 'breaking changes' label was added to any issue.
|
||
Comment 4•3 years ago
|
||
I also agree with the sentiment of GitHub lowering the barrier of entry, and I already brought that up some time ago in the dev-l10n mailing list. For me it was enough reason not to dive deeper at the time.
The question to answer I guess is what are the project's specific needs and for whom is Pontoon optimizing the dev/contribution experience for, whether established contributors or newcomers. Not sure if there's a sweet spot in the middle; unfortunately, the tools set constraints which seem to be blockers in some cases.
|
|
||
Comment 5•3 years ago
|
||
GitHub Actions potentially opens up possibilities to find a similar way to notify for times when 'more info' is needed from someone. For example an Action can be set to look for a certain label and then when applied it would notify whomever it was set up to notify, once the info needed has been given the label can be removed, and if more info is needed again the label can be re-added thus triggering the Action. This is a bit of conjecture, but I did see that there are Actions in the marketplace set up to notify for labels on Issues, and I found a blog post from someone who set up an Action to email certain people when a 'breaking changes' label was added to any issue.
Please note not everyone can set labels on GitHub issues, so a label-based workaround wouldn't be able to replace needinfo as far as I understand.
|
||
Comment 6•3 years ago
|
||
Let me chime in as well.
Using GitHub for both code and tickets definitely lowers the barrier - people know it. The recent post by Daniel Stenberg has few very interesting thoughts about GitHub as well. And I like the way you persist some very important idea to the repository directly btw.
On the other hand, GitHub was never build as project management system. It has the Issues feature, which IMO works great for bug reports, but provides very little support for agile planning. At my daily work my team uses GitHub Enterprise for code management, pull requests, code reviews and related CI triggers, but Jira is our tool to go for all the things about tickets. There are external dependencies with other teams in the company, lot of semantic fields and the most important features for me are those for planning and prioritization, what I need to work on as paid staff in the next few days - the basics like sprints and backlogs and even status of the ticket. This could all be somehow supported supported by issue tags, Milestones and Projects in GitHub, but the last time I used them it looked like a little more clever issue tags, but still lacked any sign of automation (the ticket can be only in one progress state/sprint/... etc.), backlog or even Kanban visualization and tracking. The biggest lack I see in this area is the status of the ticket - no "in progress", "blocked", "duplicate", "fixed", "qc", "closed" or how you like to track the state of a chunk of work, only assigned.
I am not paid staff working on Pontoon and I never contributed in terms of code much so I am not in your shoes. If Bugzilla works for you, I would stick with it. The greatest ideas you already persist as a documents in the repository, and to find good first issues a link to Bugzilla can work better than letting people filter in GitHub issues, which each and every project uses and manages differently and any single ticket can easily get lost there.
|
|
||
Comment 7•3 years ago
|
||
(In reply to Julen Ruiz Aizpuru from comment #5)
Please note not everyone can set labels on GitHub issues, so a label-based workaround wouldn't be able to replace needinfo as far as I understand.
That's very good point, tags are only for project maintainers, so there is no easy self-triage (bug, feature request, question, proposal, ...) by reporters possible.
|
||
Comment 8•3 years ago
|
||
I was asked to execute my right to free speech (farewell, right to free speech… ), so I am here to officially announce that I have absolutely no opinion on this matter. :-)
|
||
Comment 9•3 years ago
|
||
I wanted to add in my 2 cents to the conversation. I'm a new Developer and working with GitHub; the barrier to entry was low because of all of the information available online for GitHub. When Bugzilla was introduced to me, I was terrified of not doing the right thing; maybe that is an aspect that is positive to bring in more quilty contributors. I would Like to see the barrier is lowered, and if switching over to GitHub issues does that, so more contributors can enter the space; I'm all for that!
|
||
Comment 10•3 years ago
|
||
My thoughts are very similar to Michal's opinion. It's tough to give good feedback due to my limited experience with Bugzilla and my lack of knowledge about Pontoon's contributors-related statistics.
It's even harder when I realize that Github may not be the best possible option, feature-wise. I'm not sure which of the features are crucial to the paid staff members. As a contributor, I don't need anything more than a simple dashboard with a list of bugs assigned to me. Okay, sometimes I need to file a tracking bug. My role in the project is less responsible due to the nature of being an OSS contributor.
I know about things like OKRs and some other management-related needs of Pontoon as a software project. As a man with a few years of experience in IT, I can't omit that part. I think that there are problems that are independent from the solution we're going to choose, e.g.
- size of the backlog
- severity/priority management (I don't know if Pontoon still needs so many levels of priorities)
- gathering feedback from contributors/users -> the voting system
- bug triaging
- reporting of progress on larger tasks (tracking bugs/epics)
- custom fields that could give us more flexibility in terms of the workflow-related semantics (e.g. custom state changes * depending on the type of a bug/task)
- problems/questions/bugs raised by the maintainers of third party instances of Pontoon
- deploy-related features that can be useful, e.g. information about when the fix for a bug lands on Staging/Prod
- many more...
Most of my commercial clients and their managers use Jira/Atlassian's products. They love and hate Jira, but they stick with it because of its flexibility and customization. Jira has a dozen of features, reporting options, and a rich ecosystem of third party products. It has predefined reporting dashboards that may help a manager to track the progress on things. Maybe Pontoon as a project doesn't need such features (?) at this point. But moving away from Bugzilla and Pontoon's increasing popularity may introduce new problems.
Github always sounded like a better choice because it opens the doors to new contributors and has a rich ecosystem of plugins and additional products. In my mind, it has wider adoption than Bugzilla ever had. However, Github is limited in terms of project management features.
Github's Projects implements a simple version of Kanban boards. Kanban as a methodology sounds like something different from what we were doing in the past.
Also, Github Projects don't address more complicated concepts like tracking bugs/epics. There are some workarounds (https://github.community/t/epics-github-issues/1430), but they require additional research and resources to adjust them. And as it always is, workarounds may later introduce troubles in gathering reports/feedback.
What's worth mentioning, Github has an enormous ecosystem of third-party plugins (similarly to Jira). Some of the OSS projects use Github together with something like Zenhub or Trello. But they require another bug or epic to evaluate them.
My comment is full of doubts and questions... But, I feel that Github is a better choice than Bugzilla and expresses our open-hearted nature.
Github is a proprietary platform, but it still opens the world to a lot of projects.
I am always happy to see new people coming around. It's an inspiring and life-changing experience to work with you!
Unfortunately, my optimism isn't expressable as a metric, and every evaluation needs metrics/comparison matrices to be more than a decision based on my personal hunch/hype.
|
||
Comment 11•3 years ago
|
||
Hello,
While looking into possibly using Pontoon for the AtennaPod project, we also got to think about how 'secure' we feel about a move to Pontoon, in terms of (community) support, bugs, feasibility of deployment, etc.
At the moment, Pontoon seems very much a Mozilla-only product: open source but built specifically for Mozilla's purposes. No problem of course, but with little to no wider community of users around it, the product doesn't seem a good fit for us. Despite that (as a translator) I quite like the clean interface. So for me, not only in terms of contributing, but also in terms of using Pontoon for our project, this point is very important:
I feel like GitHub has a lower barrier of entry for many newer contributors and having the issues there as part of the repo could encourage more contributions. [as noted in #c3]
More contributions, or even 'integrated' interaction would give us more assurance that we can safely use Pontoon without being on our own if & when we do.
there is no easy self-triage (bug, feature request, question, proposal, ...) by reporters possible
There is, actually, by means of issue templates
Curious to see how the discussion will develop (or becomes stale) and what decision is taken :)
|
Reporter | |
Comment 12•3 years ago
|
||
As explained on Discourse, our primary target audience is indeed Mozilla. That said, our vision is to have decent support for 3rd party installations, which we hope will result in a higher level of contributions (bug reports, pull requests) from other organizations or individuals.
In order to get there, we need to improve Pontoon in certain areas, in particular deployment, documentation and customization. Having a low-barrier bug tracker is also very important in that setting, and the fact that we often file bugs on behalf of senior Mozilla localizers doesn't speak in favor of our existing solution.
Thanks everyone for the extensive feedback! GitHub Issues are obviously not an ideal tool, but choosing it over Bugzilla for our project is also not particularly hard decision to make. Not only will it make our roadmap and day-to-day bug management faster, it's the tool most potential contributors will already be familiar with.
In the next step we should outline the exact migration process.
|
||
Comment 13•3 years ago
|
||
|
||
Comment 14•3 years ago
|
||
*This bug has been moved to GitHub.* *Please check it out on https://github.com/mozilla/pontoon/issues.*
|
|
||
Updated•3 years ago
|
Description
•