[Pontoon] on reporting issues and providing feedback

[Julen Ruiz Aizpuru]

Hi all,

Unless I'm missing something, I understand the Bugzilla is the
preferred channel to report issues and provide feedback on Pontoon.

Considering that's the case, let me share a thought: don't you think
the barrier of entry would be lower if GH issues were used? (either
instead of or in addition to BZ). In other FOSS projects this has
shown to be the case [1].

For instance, I could see myself creating issues on GH whereas with BZ
for some reason that would rarely be the case. To be clear, I am
familiar with both systems.

Besides, all the code and pull requests are already on GitHub, and not
finding issues there would be counter-intuitive for potential new
contributors — it happened to me at least. Apart from some strict
policies (which I doubt are in place, as other Mozilla projects also
use GH issues), I can't think of any good reasons not to enable GH
issues.

I hope that makes sense and would be glad to hear whether you are
considering this option or not.

Julen.

[1] https://github.com/babel/notes/blob/master/2016-07/july-31.md#moving-from-phabricator-back-to-github-issues-repo

[Axel Hecht]

Hi Julen,
thanks for your interest in making feedback for Pontoon seamless. For
feedback and low-format bug reports, the mozilla.tools.l10n mailing list
or this list are great places. I wouldn't mind opening up a category on
discourse.mozilla.org either, if that's a place where folks are.
The reason why we have our bug list for Pontoon on bugzilla is that we
can integrate it with the rest of mozilla.
We can create a suite of bugs that show what we need to do to use ftl in
Firefox for Android, for example. This is a feature that github issues
don't support. Github projects tried this, and we've tried that, but
with very mixed results.
So that's the reason why we have pontoon open in bugzilla.
Your other question about doing both bh issues and bugzilla to me boils
down to the frustrating experience when you file an issue in one, just
to be told it's already on the other. The challenge of duplicate reports
is quite real for pontoon, because folks use different terms for similar
things, and also approach related solutions from different descriptions
of the problem.
I'd expect it to be more frustrating for folks to have two buglists that
don't correspond to each other, than to have a buglist on a system
they're not all that familiar with.
Last but not least there's the debate on whether to integrate patches
and reviews with bugs or not.
https://groups.google.com/forum/#!topic/mozilla.dev.platform/Y8kInYxo8UU
and other phabricator-at-mozilla posts in the group are full of that.
Most often, it's a tough compromise either way, it seams.
Being able to expose the localization work for a project at Mozilla on
Pontoon is important for us. (Set aside MDN, SUMO, etc.). Being able to
make the interdependencies between the work in those projects and the
work on Pontoon is really the kicker for us being on bugzilla.
Axel

Am 08.08.17 um 23:48 schrieb Julen Ruiz Aizpuru:

[Matjaz Horvat]

Hey Julen!

On Tue, Aug 8, 2017 at 11:48 PM, Julen Ruiz Aizpuru <jul...@gmail.com>
wrote:

> Hi all,
>
> Unless I'm missing something, I understand the Bugzilla is the
> preferred channel to report issues and provide feedback on Pontoon.
>

Correct.

Direct link to file a bug or submit an idea for Pontoon is this:
https://bugzilla.mozilla.org/enter_bug.cgi?product=Webtools&
component=Pontoon

And a list of currently open bugs is here:
https://bugzilla.mozilla.org/buglist.cgi?product=Webtools&co
mponent=Pontoon&resolution=---&list_id=13717426

Considering that's the case, let me share a thought: don't you think
> the barrier of entry would be lower if GH issues were used? (either
> instead of or in addition to BZ). In other FOSS projects this has
> shown to be the case [1].
>
> For instance, I could see myself creating issues on GH whereas with BZ
> for some reason that would rarely be the case. To be clear, I am
> familiar with both systems.
>

I agree - I believe the barrier to entry is lower with GitHub issues.

> Besides, all the code and pull requests are already on GitHub, and not
> finding issues there would be counter-intuitive for potential new
> contributors — it happened to me at least. Apart from some strict
> policies (which I doubt are in place, as other Mozilla projects also
> use GH issues), I can't think of any good reasons not to enable GH
> issues.
>

When Bugzilla was chosen as the bugtracker for Pontoon, GitHub Issues
weren't powerful enough for our use case. While several improvements have
been made in the last couple of years, we'd now need to migrate all the
bugs to GitHub and I wonder if we'd be able to automate that completely
(I'm thinking about dependencies for example). But hey, that's doable.

There's also a couple of features in Bugzilla we'd need to give up on
completely if we switched to GitHub. Axel already pointed out dependencies
between Pontoon bugs and bugs in other projects. The other one is private
bugs, used for reporting security vulnerabilities.

Thanks for starting the thread - it's vital that users have an easy way of
providing feedback.

-Matjaž

[Francesco Lodolo [:flod]]

Personally I feel that issues on GitHub still fall short compared to
Bugzilla:
* Flat structure, no dependencies (block, depend on).
* There's no equivalent of Needinfo. You can CC someone but it doesn't
make that an actionable flag.
* Autocomplete on @ doesn't work if this person is not a contributor to
the repository.
* You would need to use labels to overcome the lack of fields, but
labels can be set only by users with write permissions to the repository.

But, most important, you can't edit comments or rewrite history in
Bugzilla, and I think that's a requisite for a proper tracking system.
Right now I can edit a comment on GH, people will receive the original
notification via email and never know about the next edit. Or I can
remove comments all together.

Francesco

[Julen Ruiz Aizpuru]

Thanks for your insights folks.

I won't reply each message individually, but let me remind my
question/message lies around the ease of contributing and lowering the
barrier of entry.

Since everyone shared the reasons why BZ has been chosen, let me add a
few extra comments on top of that:

* Dependency on other Mozilla/BZ bugs: according to what I read, this
looks to be mostly motivated by FTL, which should be a one-time thing
(and yes, I realize I'm simplifying a years-long problem).

* Editing comments: this is also possible to do in PRs, yet that
doesn't look to be something as important as blocker to use the
feature in GH.

* Please also note how BZ falls short:

* Commits to the repo cannot automatically close bugs (unless
implemented via some bot, which tend to be quite noisy in my
experience)
* Commits and PRs cannot be referenced from BZ comments either
* Even if the scope is reduced to Mozilla, there's not certainty of
being able to ping code contributors from a BZ bug, because in GH it's
extremely easy to contribute (even without a code editor and VCS-fu!)

* I am also aware of the "technical superiority" of being able to
define custom fields or making issues actionable by requesting
feedback on individuals.

But all in all I'm not trying to convince anyone one option is
better/worse; each alternative has its pros and cons depending on
what's being considered important.

As said, my initial message is written around lowering the barrier of
entry, and I believe (and I'm not the only one), GH issues is a better
fit in that regards. I just hope this aspect receives more importance
and contributing via GH issues can be reconsidered.

Regards,
Julen.

[Adrian Gaudebert]

Hi Julen,

Thanks for your feedback on lowering the barrier to entry to Pontoon! Here
are my thoughts on this.

First of all, for the reasons Axel described and more, it is absolutely not
a good idea to have 2 bug reporting systems. So we have to choose between
GitHub's issues and bugzilla. I very much agree that bugzilla is a
nightmare to use, and github is much more user-friendly. However, we
Mozilla employees do have use for bugzilla's flexibility and many features.
It's not only the current FTL work. Throughout my many years at Mozilla,
I've made plenty of usage of needinfo, blocked by, depends on, flags,
whiteboard, and many other features that do not exist in GitHub or are less
efficient there. Add to that the fact that most of Mozilla uses bugzilla,
which makes it weird to use something else (it has happened, and probably
still does, but most of the products I know that have used github issues
have moved to bugzilla at some point in their life).

tl;dr: I don't think we can afford to move to github issues, because
bugzilla has many features that are very important to us.

However, I actually don't think that is a problem. If your goal is to lower
the barrier of entry to Pontoon, I believe filing bugs is not the most
important thing to address right now. As Axel said, there are many ways for
users to inform developers of problems they encounter, from mailing lists
to Telegram channels. This is the point of view of someone who freshly
joined this team, so maybe I'm missing something out, but I have the
sensation that communication is quite easy, and key people are easy to
reach out. Also, my naive self is convinced that people who care but cannot
use Bugzilla will find another way to communicate with us. All in all, I
strongly believe we are in a fine state at the moment!

Hope this helps!

Cheers,
Adrian

On Thu, Aug 10, 2017 at 4:35 PM, Julen Ruiz Aizpuru <jul...@gmail.com>
wrote:

> _______________________________________________
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
>