RFC: Re-opening Github Issues

[Michael Henretty]

People of Gaia,

A small group of us (Dietrich, Reza, Gregor, and myself) have been brainstorming how to make Gaia more approachable for first-time contributors [1]. One of our thoughts is that javascript developers are very familiar with Github workflows (issues, PRs), but are perhaps intimidated by Bugzilla. So we would like to re-open Github issues to help us bridge the gap.

Now, we are well aware this has been a controversial issue in the past [2]. We even made an etherpad to try and make sure we fully understand the problem [3]. So before we start discussing old problems, allow me to tell you how Github issues are going to be different this time.

First, and perhaps most importantly, sheriffs, release managers, EPMs, and even core Gaia developers can all ignore Github issues. Bugzilla will remain the one source of truth, period. Instead, Github issues will only be used as an outreach tool for new contributors. They will be curated by a small group of Gaia volunteers whose job it will be to open a Bugzilla bug for each issue, and help guide potential contributors through the Bugzilla process. We also have the idea of filing GH issues for mentored Bugzilla bugs, since we believe a lot of potential contributors will look at Github issues first to try and find something to help out with.

Again, existing Bugzilla workflows/queries/triages will be unaffected. Github issues will be the sole responsibility of these aforementioned Gaia volunteers, and if we fail to keep up or it proves ineffective as an outreach tool we will simply close Github issues again. However, if our assumptions are correct we may find that we have a new source of contribution, and wouldn't that be swell?

Thoughts/concerns?

-Michael, Reza, Dietrich, Gregor

1.) https://wiki.mozilla.org/FirefoxOS/Participation
2.) https://groups.google.com/d/topic/mozilla.dev.gaia/2Q93wAEmjj4/discussion
3.) https://etherpad.mozilla.org/reopen-github-issues

[Naoki Hirata]

I will say that at this time rather than having addons to fix issues, I would prefer to actually have the polish/papercuts fixed.  People shouldn't need to have addons to get these papercuts fixed.  If we're driving for quality, and trying to engage community, I think this will help.

Having said that, yes, I have concerns.  Just two for now, possibly more later:
1) QA doesn't have the bandwidth to look at both and follow the comments on each and every thread.

2) If the comments and integration is bidirectional, it could potentially save us; at the same time potential malicious people can spam us easier.

I think it's worth another look/investigation if we can get contributors to help us with the papercuts and polish if not more.

Regards,

Naoki

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

[Dietrich Ayala]

+1 to addons not being the right direction for fixing core OS bugs and daily-use papercuts. Maybe useful as a first-step towards making a proper fix, but realistically it's only a matter of time before the addon breaks due to core changes we make.

[Zibi Braniecki]

I was thinking about it the other day - now, with the ability to login to our b.m.o via github account, how about a binding?

You create a github issue, it creates a bug in bugzilla, and comments in the issue with a link. People can follow and participate with their github accounts.

If we wan to be fancy, we could rely bugzilla comments into the github issue, but I'm not sure if that's even needed.

zb.

[Kumar Rishav]

+1 zibi

[Naoki Hirata]

Not sure if I understand the exact mechanism.

Do you mean to say we can have github integration where creating a new github issue will redirect them to create a bugzilla bug and then they are working with bugzilla moving forward?  That would be awesome!

The reason why I think it does have to be bidirectional, is that there are comments and feedback in bugzilla that the web dev community will need to see and respond to.

If web dev community are strictly looking at github, then they will miss these comments....

On Wed, Aug 5, 2015 at 11:23 AM, Kumar Rishav <rish...@gmail.com> wrote:

+1 zibi

On 5 Aug 2015 23:48, "Zibi Braniecki" <zbigniew....@gmail.com> wrote:

I was thinking about it the other day - now, with the ability to login to our b.m.o via github account, how about a binding?

You create a github issue, it creates a bug in bugzilla, and comments in the issue with a link. People can follow and participate with their github accounts.

If we wan to be fancy, we could rely bugzilla comments into the github issue, but I'm not sure if that's even needed.

zb.

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

[Michael Henretty]

On Wed, Aug 5, 2015 at 8:04 PM, Naoki Hirata <nhi...@mozilla.com> wrote:

I will say that at this time rather than having addons to fix issues, I would prefer to actually have the polish/papercuts fixed.  People shouldn't need to have addons to get these papercuts fixed.  If we're driving for quality, and trying to engage community, I think this will help.

Completely agreed. FWIW, I don't allow add-ons in Hackerplace that are just as easily fixed in Gaia. Communication should be clear that add-ons are not for bug fixes in Gaia.

 

Having said that, yes, I have concerns.  Just two for now, possibly more later:
1) QA doesn't have the bandwidth to look at both and follow the comments on each and every thread.

QA can also ignore github issues. Bugzilla will still be the one source of truth for you too.

2) If the comments and integration is bidirectional, it could potentially save us; at the same time potential malicious people can spam us easier.

Mirroring is not in the plan. Think of a Github as akin to a soft-landing page for Bugzilla. New contributors will come there and then we guide them into Bugzilla. It will be the job of the volunteers to make sure any important discussion happens on Bugzilla.

 

I think it's worth another look/investigation if we can get contributors to help us with the papercuts and polish if not more.

Yup, that's part of this plan. We file Github issues that are mentored bugs most likely focused around polish. Again, this is the job of the volunteers to curate this list. More volunteers always welcome!

[Andrew Sutherland]

On 08/05/2015 01:46 PM, Michael Henretty wrote:
> We also have the idea of filing GH issues for mentored Bugzilla bugs,
> since we believe a lot of potential contributors will look at Github
> issues first to try and find something to help out with.

This seems like the biggest possible win. Mozilla has a surfeit of
contribution opportunities and funnels to get them there which
frequently end up confusing and overwhelming[1]. Seeing a curated
collection of easily actionable issues in the expected github idiom
would be a tremendous win since the Mozilla contribution process can
otherwise be overwhelming.

I think people filing new issues is less likely to result in actionable
paths and instead be another source of dupes, but I think that's an
acceptable trade-off given the potential of surfacing actionable
contribution points.

Andrew

1: I think http://www.joshmatthews.net/bugsahoy/ and the more guided
http://whatcanidoformozilla.org are probably the best out there for
these use-cases, but I inevitably have trouble remembering their names
and things like https://www.mozilla.org/en-US/contribute/ tend to
obscure my attempts to get there.

[Michael Henretty]

On Wed, Aug 5, 2015 at 8:18 PM, Zibi Braniecki <zbigniew....@gmail.com> wrote:

I was thinking about it the other day - now, with the ability to login to our b.m.o via github account, how about a binding?

You create a github issue, it creates a bug in bugzilla, and comments in the issue with a link. People can follow and participate with their github accounts.

If we wan to be fancy, we could rely bugzilla comments into the github issue, but I'm not sure if that's even needed

We have discussed some tighter integration, like using tools to automatically open a new bugzilla bug for every GH issue or PR not already tied to a bug. But mirroring is not what we are going for just yet, since we want it to be clear Bugzilla is still our main tracking tool.

Our first goal here is to prove that Github issues are indeed a useful outreach venue, and then we can get, as you say, fancy.

[Jim Porter]

On 08/05/2015 12:46 PM, Michael Henretty wrote:
> A small group of us (Dietrich, Reza, Gregor, and myself) have been
> brainstorming how to make Gaia more approachable for first-time
> contributors [1]. One of our thoughts is that javascript developers are
> very familiar with Github workflows (issues, PRs), but are perhaps
> intimidated by Bugzilla.

Have we actually received feedback saying that? So far, this proposal
seems to be suggesting that new contributors would file issues for
things they want to fix, and then the community managers would clone the
bug into Bugzilla. For getting new contributors, I think this is
completely backwards.

Since the Firefox OS userbase is fairly small, I doubt there are that
many people who have devices and have found good first bugs on their own
to fix. I think it's a lot more likely that new contributors will be
people with experience in Javascript who want to branch out from just
making web pages. For that kind of developer, it would be better to have
a list of mentored bugs so that they can look through the list and take
something that strikes their fancy. The people who best know what bugs
are both desirable and easy to work on are the module owners; we should
be responsible for maintaining a list of good first bugs for this
purpose. Of course, we could make a fancy web page that doesn't look
like Bugzilla to show off these bugs if we're worried about Bugzilla's UI.

More generally, my experience with new contributors (mainly in the
Thunderbird project) has suggested that the people who have sufficient
dedication to follow through on even a simple patch are the people who
need *less* help from core developers, not more. I've tried many
different ways to keep new contributors from abandoning their patches
(if they even get so far as posting a patch), but it seems that there's
very little I can do to ensure that a new contributor successfully lands
a patch.

Probably the biggest stumbling block I see in Thunderbird (and I imagine
it holds true in Gaia too) isn't Bugzilla; it's the build process. Both
Thunderbird and Gaia have arcane build systems that can easily take a
few days to get working on a new machine. That's a great way to
frustrate someone into giving up before they even get started. Another
big issue is lack of documentation; I sure wouldn't want to dig through
dozens of source files to decipher what's going on just because the core
developers were too lazy to document anything. Hell, if anything, Gaia
is worse about this than Thunderbird. Even I don't know how to work on
Gaia without a real device, and I've been doing this full-time for three
years now.

- Jim

[Fred Lin]

I tend to support bugzilla lite or bugzilla mobile(if there is) since its more pragmatic to file issues with real device and it's way easier to attach screenshots. Many telephony&hardware api related issues are only debuggable via real device.

Bi-directional sync can't solve every problem and pretend all developer still works on bugzilla.
http://www.joelonsoftware.com/articles/LeakyAbstractions.html

For example,
1. if the contributor provide the pull request, they still need set review? at bugzilla.

2. if the contributor want to ni someone, should we keep a mapping from @github to :bugzilla?

We could update gaia README to ask people go to bugzilla explicitly.

For build process It's usually take days for new developer to setup a workable environment to develop gaia.

There are several attempts to make the process automatically via wrapping the setup instructions into VM

https://github.com/gasolin/foxbox
https://github.com/wilsonpage/b2g-vm

But it still a long learning curve to learn to use VM (especially for windows user) then start the real gaia development.

regards
--

Fred

On Thu, Aug 6, 2015 at 6:53 AM, Jim Porter <jpo...@mozilla.com> wrote:

On 08/05/2015 12:46 PM, Michael Henretty wrote:

> A small group of us (Dietrich, Reza, Gregor, and myself) have been
> brainstorming how to make Gaia more approachable for first-time
> contributors [1]. One of our thoughts is that javascript developers are
> very familiar with Github workflows (issues, PRs), but are perhaps
> intimidated by Bugzilla.

[David Rajchenbach-Teller]

Just two cents: Servo uses github pull requests and a bot called
HighFive, which works very nicely. It thanks submitters, picks
reviewers, launches unit tests, informs submitters of progress, etc.

Cheers,
David

[Michael Henretty]

On Thu, Aug 6, 2015 at 12:53 AM, Jim Porter <jpo...@mozilla.com> wrote:

Have we actually received feedback saying that? So far, this proposal
seems to be suggesting that new contributors would file issues for
things they want to fix, and then the community managers would clone the
bug into Bugzilla. For getting new contributors, I think this is
completely backwards.

Since the Firefox OS userbase is fairly small, I doubt there are that
many people who have devices and have found good first bugs on their own
to fix. I think it's a lot more likely that new contributors will be
people with experience in Javascript who want to branch out from just
making web pages. For that kind of developer, it would be better to have
a list of mentored bugs so that they can look through the list and take
something that strikes their fancy. The people who best know what bugs
are both desirable and easy to work on are the module owners; we should
be responsible for maintaining a list of good first bugs for this
purpose. Of course, we could make a fancy web page that doesn't look
like Bugzilla to show off these bugs if we're worried about Bugzilla's UI.

This is exactly the use case we are trying to cover with Github issues. Our thinking is, why re-invent the wheel with a new webpage that wraps the UI of bugzilla (we already have one btw, [1]), when Github issues serves this purpose really well. Take a look at the top Javascript projects on Github [2]. They all have a vibrant GH-issues community. The majority of issues don't go more than a day without some activity from maintainers, which is not true for Bugzilla. It is our hypothesis that the people you mention, experienced Javascript programmers looking to branch out, are familiar with GH issues and will look there first for stuff to help out with. If they see a problem in the code or have a suggestion, they might also file an issue. In this case, we will guide them into Bugzilla and help with the hard parts like putting it in the proper component and flagging the right people so it doesn't get lost.

So again, the workflow for normal Gaia devs remains unaffected. Module owners like yourself will still maintain a list of good first bugs and mark them on bugzilla as such. It will be the job of the volunteers to open gh-issues for these type bugs. At first this list will be highly curated, but down the road perhaps we can automate it (ie. open an issue for any bug tagged with [good-first-bug]). Github issues will not be used as a bug tracking tool. It's just a honey-pot for contributors.

 

Probably the biggest stumbling block I see in Thunderbird (and I imagine
it holds true in Gaia too) isn't Bugzilla; it's the build process. Both
Thunderbird and Gaia have arcane build systems that can easily take a
few days to get working on a new machine. That's a great way to
frustrate someone into giving up before they even get started. Another
big issue is lack of documentation; I sure wouldn't want to dig through
dozens of source files to decipher what's going on just because the core
developers were too lazy to document anything. Hell, if anything, Gaia
is worse about this than Thunderbird. Even I don't know how to work on
Gaia without a real device, and I've been doing this full-time for three
years now.

 

I completely agree that the build system and it's various state of brokenness on various platforms is a huge stumbling block. This is also something the small group of volunteers is looking at. Right now, there are no less than 4 competing ways to run Gaia [3]. It needs to be simpler and familiar to web devs. So we are currently looking at unifying the desktop environment (mulet over b2g-desktop/nightly). If people can download Gaia, run it with a single command, and then hit F5 to see changes they make, I think this solves the build problems for the 80% case. Turns out this is something other people are already actively working on, and probably orthogonal to the GH issues discussion anyway.

1.) http://www.joshmatthews.net/bugsahoy/?b2g=1
2.) https://github.com/search?q=stars:%3E1&s=stars&type=Repositories&l=javascript
3.) https://developer.mozilla.org/en-US/Firefox_OS/Developing_Gaia

[Michael Henretty]

On Thu, Aug 6, 2015 at 4:08 AM, Fred Lin <fl...@mozilla.com> wrote:

I tend to support bugzilla lite or bugzilla mobile(if there is) since its more pragmatic to file issues with real device and it's way easier to attach screenshots. Many telephony&hardware api related issues are only debuggable via real device.

Existing Bugzilla/Bugzilla Lite workflows will remain unaffected. There is no plans to push people away from using that if they already are.
 

Bi-directional sync can't solve every problem and pretend all developer still works on bugzilla.
http://www.joelonsoftware.com/articles/LeakyAbstractions.html

We won't be doing bi-directional sync. There will of course be a link to Bugzilla in the Github Issue, but Bugzilla will remain the source of truth. Github issues will not be a wrapper, abstraction, or cleaner-UI version of Bugzilla. It's just an outreach tool, and if it proves more work than it is effective we will deactivate them again.

 

For example,
1. if the contributor provide the pull request, they still need set review? at bugzilla.

Of course. That is what the volunteers will help them with.

 

2. if the contributor want to ni someone, should we keep a mapping from @github to :bugzilla?

Maybe down the road we will automate the mapping somehow. But let's start simple and allow the volunteers to decide how best to shepherd new contributors into Bugzilla.

 

We could update gaia README to ask people go to bugzilla explicitly.

We can do this regardless. Our hypothesis is that the friction for creating a Github issue is much lower than Bugzilla for Gaia newbies. For instance, the new bug form in Bugzilla has >20 inputs, the new GH-issue form has 2. Perhaps our hypothesis is wrong, and we can argue until we are blue in the face about what web devs actually want, but I'd rather test this out in the wild.

 

For build process It's usually take days for new developer to setup a workable environment to develop gaia.

There are several attempts to make the process automatically via wrapping the setup instructions into VM

https://github.com/gasolin/foxbox
https://github.com/wilsonpage/b2g-vm

But it still a long learning curve to learn to use VM (especially for windows user) then start the real gaia development.

Great! This is still very relevant and useful work.

[Michael Henretty]

Something that I left out of this conversation is what happens to pull requests not attached to a Bugzilla bug. It is another hypothesis of ours that when new contributors see a problem, rather than filing an issue they will just fork the code and submit a PR. We see this as a potential outreach avenue as well, and we want to find a way to catch them and shepherd into Bugzilla. Right now they are all too easily lost in the ocean:

https://github.com/mozilla-b2g/gaia/pull/30714

[Jim Porter]

On 08/06/2015 07:29 AM, Michael Henretty wrote:
> This is exactly the use case we are trying to cover with Github issues.
> Our thinking is, why re-invent the wheel with a new webpage that wraps
> the UI of bugzilla (we already have one btw, [1]), when Github issues
> serves this purpose really well. Take a look at the top Javascript
> projects on Github [2]. They all have a vibrant GH-issues community.

While true, that's not a causal relationship. If there's more evidence
that not using GitHub is a stumbling block for new contributors, then
it's worth a shot, but my guess is that the issue tracker we use is
pretty far down the list of "things that discourage new contributors".
Without any such evidence, I worry that we'd just end up cargo-culting
more successful projects without understanding why they're successful.

> If they see a problem in the code or have a suggestion, they might
> also file an issue. In this case, we will guide them into Bugzilla and
> help with the hard parts like putting it in the proper component and
> flagging the right people so it doesn't get lost.

I think we should be trying to teach new contributors proper bug
protocol from day one. I'm not sure how letting users file GitHub issues
and then telling them, "hey, this isn't actually how you do it" is going
to help that. That would probably just annoy me if I were a new contributor.

We do need to have better ways to teach new people our process though. I
just looked at our README, and frankly, it stinks for helping guide new
contributors. There's a bunch of space wasted for badly-formatted links,
and then the "Hacking Gaia" section, which should probably be made more
noticeable, takes people to a disorganized mess of a tutorial. Every
section is too long and digresses into topics that no one but a core dev
would care about. Would a new contributor really care about the branch
structure we use? They should just be working on master anyway.

As it stands right now, even if we had volunteers keeping track of all
the new GitHub issues, it would still be a pain to help them because we
don't appear to have *any* good documents describing how to get your
first Gaia build working. Even worse, we don't really explain how to use
Bugzilla. A quick guide on the important parts would be great, even if
we did eventually decide to reopen GitHub issues; then, we could just
give people a link that tells them what to do in the future, rather than
trying to explain it ourselves.

> So again, the workflow for normal Gaia devs remains unaffected. Module
> owners like yourself will still maintain a list of good first bugs and
> mark them on bugzilla as such.

Well, I'm not sure if we really are unaffected. :) My experience has
been that modules *don't* have a list of good first bugs. Module owners
and peers would have to sit down and make those lists. It's definitely
something we need to focus on, though.

I guess my overall feelings are that, while reopening GitHub issues
might help, I think we have bigger problems we should try to tackle
first. In roughly descending order of importance: 1) module owners need
to maintain lists of good first bugs, 2) the build process sucks, 3) the
documentation (especially the README) sucks. I think all of these are
prerequisites to making GitHub issues work, and in fact, they may be
sufficient to solve our problems.

That said, if reopening GitHub issues forces us to fix our other
problems, I'm all for it, since we can get rid off the stuff that
doesn't work later.

- Jim

[Jim Porter]

On 08/06/2015 07:58 AM, Michael Henretty wrote:
> Something that I left out of this conversation is what happens to pull
> requests not attached to a Bugzilla bug. It is another hypothesis of
> ours that when new contributors see a problem, rather than filing an
> issue they will just fork the code and submit a PR. We see this as a
> potential outreach avenue as well, and we want to find a way to catch
> them and shepherd into Bugzilla.

Since we already have autolander, couldn't we have it also post a brief
message to explain that you need to file a bug if you didn't already?
Right now (or last I checked), it just whines that you didn't format
your PR's title correctly, e.g.
<https://github.com/mozilla-b2g/gaia/pull/29754>.

A quick link explaining the accepted process would be a big help; all
the guides I've seen are overly verbose; it really just needs to be 1)
file bug, 2) open a PR, 3) flag the right person for review.

- Jim

[Kevin Grandon]

> Since we already have autolander, couldn't we have it also post a brief
message to explain that you need to file a bug if you didn't already?
Right now (or last I checked), it just whines that you didn't format
your PR's title correctly, e.g.

Yes, I'm happy to change the Autolander message to whatever would help contributors. Feel free to suggest an alternative message and I will make it so.

Best,

Kevin

On Thu, Aug 6, 2015 at 6:08 PM, Jim Porter <jpo...@mozilla.com> wrote:

On 08/06/2015 07:58 AM, Michael Henretty wrote:

> Something that I left out of this conversation is what happens to pull
> requests not attached to a Bugzilla bug. It is another hypothesis of
> ours that when new contributors see a problem, rather than filing an
> issue they will just fork the code and submit a PR. We see this as a
> potential outreach avenue as well, and we want to find a way to catch
> them and shepherd into Bugzilla.

Since we already have autolander, couldn't we have it also post a brief
message to explain that you need to file a bug if you didn't already?
Right now (or last I checked), it just whines that you didn't format
your PR's title correctly, e.g.
<https://github.com/mozilla-b2g/gaia/pull/29754>.

A quick link explaining the accepted process would be a big help; all
the guides I've seen are overly verbose; it really just needs to be 1)
file bug, 2) open a PR, 3) flag the right person for review.

- Jim

[Augustin Trancart]

I agree with Jim, the weak part of the process is when you have a PR before opering a bug. It could be very useful to have autolander automatically comment a gh PR.

To be a bit more specific, and to rephrase what Jim and others have said, I would propose:
- If autolander can find the bug on bugzilla (because there is a bug number in the commit/PR title), it would just post a link to the issue in the PR , in addition to linking the PR in bugzilla. Being able to navigate back and forth between bugs and PR is something I miss a lot, and would reduce the overhead of using 2 tools. Web is about links, let's put some!
- If it cannot, then post a comment explaining what are the next steps or linking to a mdn page, maybe a modified version of [1] for this specific workflow. Also posting a link to [2] that will prefill the summary field would be awesome. However, it does NOT create a bugzilla issue for you. This is a learning process, you need to guide the user, but they need to do it themselves.

Kevin, is it something doable?

Concerning bugzilla, as a contributor, I don't see how filling a bug for firefox OS is complicated. You just need to go to bugzilla.mozilla.org, and then, the process is pretty straigthforward: file a bug > firefox OS > then you have basically 3 fields to enter. The hardest is to choose the component, but it is not that complicated, especially if you are filling a bug for an app. I feel like you guys are overestimating the complexity of this process :-) That's not where I had difficulties when I entered the project.

Moreover, I feel like opening GH issues will only confused people. I've already worked in a project with 2 bug tracking tools, and every attempt to synchronize between them/have a clear workflow for when to use one over the other have failed (and the team was very small, 4 people, I can't imagine what will happen with gaia). Actually, I'm not far from thinking that having 2 tools for the same task, whatever it is, is bound to failure (ok, let's be honest, I totally think so :-) ).
I don't believe at all that GH issues will act as soft landing. If you allow them, people will just get trapped in them and won't use bugzilla any more (why would they do this?). Moreover, if sheriffs, release managers, EPMs, core Gaia developers and qa can all ignore Github issues, then nobody will look at them. Michael, I'm afraid you won't have volunteers for this task, at least never enough. So instead of creating a soft transition, gaia bugs will be separated in two independant worlds.
But, most probably, they'll have to look at it anyway, and all the duplication problems will come back.

IMO keeping bugzilla interface simple and straightforward (and improving it) is the way to go. But honestly it's not that bad already.

[1] https://developer.mozilla.org/en-US/Firefox_OS/Developing_Gaia/Submitting_a_Gaia_patch
[2] https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox OS

Augustin Trancart
Phoxygen

On 07/08/2015 03:34, Kevin Grandon wrote:

> Since we already have autolander, couldn't we have it also post a brief
message to explain that you need to file a bug if you didn't already?
Right now (or last I checked), it just whines that you didn't format
your PR's title correctly, e.g.

Yes, I'm happy to change the Autolander message to whatever would help contributors. Feel free to suggest an alternative message and I will make it so.

Best,

Kevin

On Thu, Aug 6, 2015 at 6:08 PM, Jim Porter <jpo...@mozilla.com> wrote:

On 08/06/2015 07:58 AM, Michael Henretty wrote:

> Something that I left out of this conversation is what happens to pull
> requests not attached to a Bugzilla bug. It is another hypothesis of
> ours that when new contributors see a problem, rather than filing an
> issue they will just fork the code and submit a PR. We see this as a
> potential outreach avenue as well, and we want to find a way to catch
> them and shepherd into Bugzilla.

Since we already have autolander, couldn't we have it also post a brief
message to explain that you need to file a bug if you didn't already?
Right now (or last I checked), it just whines that you didn't format
your PR's title correctly, e.g.
<https://github.com/mozilla-b2g/gaia/pull/29754>.

A quick link explaining the accepted process would be a big help; all
the guides I've seen are overly verbose; it really just needs to be 1)
file bug, 2) open a PR, 3) flag the right person for review.

- Jim
_______________________________________________
dev-gaia mailing list
dev-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-gaia

[Kartikaya Gupta]

On Fri, Aug 7, 2015 at 5:13 AM, Augustin Trancart
<augustin...@phoxygen.com> wrote:
> Concerning bugzilla, as a contributor, I don't see how filling a bug for
> firefox OS is complicated. You just need to go to bugzilla.mozilla.org, and
> then, the process is pretty straigthforward: file a bug > firefox OS > then
> you have basically 3 fields to enter. The hardest is to choose the
> component, but it is not that complicated, especially if you are filling a
> bug for an app. I feel like you guys are overestimating the complexity of
> this process :-) That's not where I had difficulties when I entered the
> project.

And for those who do find this "filing a bug" process complex,
Bugzilla does support the creation of a simplified form - see
https://bugzilla.mozilla.org/page.cgi?id=custom_forms.html for a list
- which can be used to assist people familiar with GH issue creation
but not Bugzilla. I would favour using that instead of turning GH
issues back on.

kats

[Michael Henretty]

Thanks for the feedback Jim, Augustin, et al! Based on this feedback, it sounds like there are a number of things we should shore up first before considering GH issues as an outreach channel. Here's is what I've got so far:

1.) Fix the build process.

  - To me, contributing to Gaia as a web developer shouldn't require compiling anything (at least not for the 90% good-first-bug cases). But we do need a clearer and faster process for running Gaia both on desktop and on device. I think a first step here is to shore up the running Gaia on desktop part by killing b2g-desktop/gaia-in-nightly and make mulet the desktop runtime of choice. As part of this, let's make sure it's easy to install and keep mulet up to date, and then run the latest Gaia on it. The on-device story is a little more murky, but flashing the latest build coupled with any Gaia changes should be as simple as running a command or hitting a button in WebIDE. I believe all this work is already underway (bug 1166276, bug 943878, etc), but we should continue to push for it as part of the contributor story.

I agree we also need to fix the building mulet/b2g arm story on all platforms, and perhaps a container is the best way forward there(?). But I don't think this should block other efforts for getting new contributors in the meantime.

2.) Fix the documentation.

  - I agree that Hacking Gaia [1] has a lot of information and is perhaps overwhelming for someone just getting started. I like Jim's suggestion of having a "quick guide" for new contributors. Let's make an MDN landing page that is a concise step-by-step guide for how to go from zero to landing your first patch in Gaia, including only the necessary information (find good-first bug, get gaia, run gaia, modify code, re-run gaia, open pr, get review, checkin-needed). We've started a rough outline [2], but we'll make this a top priority since it blocks a lot of the other things we are trying to do.

And yes the Gaia README is indeed in poor shape. A lot of the information there is a repeat of stuff on MDN and it's not immediate clear where to go first. Let's have a separate conversation about how to fix the README, but I think it makes sense to have this block other outreach work as well.

3.) Fix dangling pull request.

 - Sounds like we have an easy fix here; autolander can comment on PRs for which it can't find a bugzilla bug. Augustin's suggestion sounds like a good idea to me. Perhaps we can make dangling PRs link to the aforementioned "quick guide" once we get it.

4.) Fix the feedback loop.

 - One thing that is clear is that we don't understand our contributors well enough. If we knew better who they were, how they found Gaia, what their experience was trying to contribute, and what they would like improved, we could take smarter actions on their behalf. No matter what steps we take here we need to engage more throughout the process. I think this is the most important and difficult problem to fix, so suggestions are encouraged!

I'd still like to consider Github issues as a curated good-first-bug list down the road, but I will concede that the points raised by Jim and company need to be addressed first. If you think I have missed anything in the above 4 points, please reply. Also, anyone is welcome of course to form their own group and work on what they think is most important here (like compiling b2g on Mac??).

Thanks,

Michael

1.) https://developer.mozilla.org/en-US/Firefox_OS/Developing_Gaia
2.) https://etherpad.mozilla.org/gaia-pathway

On Fri, Aug 7, 2015 at 11:13 AM, Augustin Trancart <augustin...@phoxygen.com> wrote:

I agree with Jim, the weak part of the process is when you have a PR before opering a bug. It could be very useful to have autolander automatically comment a gh PR.

To be a bit more specific, and to rephrase what Jim and others have said, I would propose:
- If autolander can find the bug on bugzilla (because there is a bug number in the commit/PR title), it would just post a link to the issue in the PR , in addition to linking the PR in bugzilla. Being able to navigate back and forth between bugs and PR is something I miss a lot, and would reduce the overhead of using 2 tools. Web is about links, let's put some!
- If it cannot, then post a comment explaining what are the next steps or linking to a mdn page, maybe a modified version of [1] for this specific workflow. Also posting a link to [2] that will prefill the summary field would be awesome. However, it does NOT create a bugzilla issue for you. This is a learning process, you need to guide the user, but they need to do it themselves.

Kevin, is it something doable?

Concerning bugzilla, as a contributor, I don't see how filling a bug for firefox OS is complicated. You just need to go to bugzilla.mozilla.org, and then, the process is pretty straigthforward: file a bug > firefox OS > then you have basically 3 fields to enter. The hardest is to choose the component, but it is not that complicated, especially if you are filling a bug for an app. I feel like you guys are overestimating the complexity of this process :-) That's not where I had difficulties when I entered the project.

Moreover, I feel like opening GH issues will only confused people. I've already worked in a project with 2 bug tracking tools, and every attempt to synchronize between them/have a clear workflow for when to use one over the other have failed (and the team was very small, 4 people, I can't imagine what will happen with gaia). Actually, I'm not far from thinking that having 2 tools for the same task, whatever it is, is bound to failure (ok, let's be honest, I totally think so :-) ).
I don't believe at all that GH issues will act as soft landing. If you allow them, people will just get trapped in them and won't use bugzilla any more (why would they do this?). Moreover, if sheriffs, release managers, EPMs, core Gaia developers and qa can all ignore Github issues, then nobody will look at them. Michael, I'm afraid you won't have volunteers for this task, at least never enough. So instead of creating a soft transition, gaia bugs will be separated in two independant worlds.
But, most probably, they'll have to look at it anyway, and all the duplication problems will come back.

IMO keeping bugzilla interface simple and straightforward (and improving it) is the way to go. But honestly it's not that bad already.

[1] https://developer.mozilla.org/en-US/Firefox_OS/Developing_Gaia/Submitting_a_Gaia_patch
[2] https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox OS

Augustin Trancart
Phoxygen

On 07/08/2015 03:34, Kevin Grandon wrote:

> Since we already have autolander, couldn't we have it also post a brief
message to explain that you need to file a bug if you didn't already?
Right now (or last I checked), it just whines that you didn't format
your PR's title correctly, e.g.

Yes, I'm happy to change the Autolander message to whatever would help contributors. Feel free to suggest an alternative message and I will make it so.

Best,

Kevin

On Thu, Aug 6, 2015 at 6:08 PM, Jim Porter <jpo...@mozilla.com> wrote:

On 08/06/2015 07:58 AM, Michael Henretty wrote:

> Something that I left out of this conversation is what happens to pull
> requests not attached to a Bugzilla bug. It is another hypothesis of
> ours that when new contributors see a problem, rather than filing an
> issue they will just fork the code and submit a PR. We see this as a
> potential outreach avenue as well, and we want to find a way to catch
> them and shepherd into Bugzilla.

Since we already have autolander, couldn't we have it also post a brief
message to explain that you need to file a bug if you didn't already?
Right now (or last I checked), it just whines that you didn't format
your PR's title correctly, e.g.
<https://github.com/mozilla-b2g/gaia/pull/29754>.

A quick link explaining the accepted process would be a big help; all
the guides I've seen are overly verbose; it really just needs to be 1)
file bug, 2) open a PR, 3) flag the right person for review.

- Jim
_______________________________________________
dev-gaia mailing list
dev-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-gaia

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

[Dale Harvey]

A lot of people have questioned quite how hard bugzilla is to use for new contributors, while I fully agree that github issues are nowhere near powerful enough to be used on the scale that we require across dev / qa / release management / sheriffing etc it is pretty hard to overstate quite how much of a barrier bugzilla (and similiarly jira) are for new contributors. Dietrich and I have both spent quite a few years mentoring first time student contributors in various programs, along with experience from other open source projects and contribution programs I most definitely agree if we can ramp people up via github issues then it will be a vastly easier process.

I fully agree on the other issues that should be fixed, build systems and documentation, dangling pull requests etc are all important issues, but I would really like to see a little less stop energy given to ideas that have the potential to improve other areas. I dont think a contribution process should be blocked by fixing the build, in fact I think by being exposed to new more new contributors we may 1. get a lot of fixes to the workflow (documentation etc) 2. be more exposed to the problems that new contributors see.

I think the process of mentored bugs is quite challenging to do correctly, for github issues I would really love to see somewhat of a process like https://medium.com/@kentcdodds/first-timers-only-78281ea47455 applied to it.

> Something that I left out of this conversation is what happens to pull
> requests not attached to a Bugzilla bug. It is another hypothesis of
> ours that when new contributors see a problem, rather than filing an
> issue they will just fork the code and submit a PR. We see this as a
> potential outreach avenue as well, and we want to find a way to catch
> them and shepherd into Bugzilla.

[Jim Porter]

On 08/07/2015 09:13 AM, Dale Harvey wrote:
> Dietrich and I have both spent quite a few years mentoring first time
> student contributors in various programs, along with experience from
> other open source projects and contribution programs I most
> definitely agree if we can ramp people up via github issues then it
> will be a vastly easier process.

Do you have any more details on this? When I got started with Mozilla
(via Thunderbird), I was only a couple years out of college and none too
experienced with Bugzilla. However, I didn't have trouble getting up to
speed (at least, with Bugzilla), and this was back when the UI was even
worse. It's possible my experience is an outlier, though.

Maybe one of the reasons we're disagreeing is because we're imagining
different kinds of "new contributors". Since you explicitly mention
students, I'm guessing that's your main focus. We probably want to ask
ourselves what our goals are: do we want to teach new programmers how to
work in the "real world", or do we want to find volunteers who can make
significant contributions to the project? Students can fall into either
category, but I imagine the former is more common.

> I fully agree on the other issues that should be fixed, build
> systems and documentation, dangling pull requests etc are all
> important issues, but I would really like to see a little less stop
> energy given to ideas that have the potential to improve other
> areas.

Regarding "stop energy", I disagree. If anything, I think ideas become
*better* when folks who disagree argue their positions. Being forced to
defend your idea can help you to refine it as you make your argument,
even if you never concede to the other side. I don't seem to have
convinced Michael et al to wholly abandon the "GitHub issue" plan, but
hopefully they have some more ideas for how to solve the underlying
problem. :)

- Jim

[Gervase Markham]

On 07/08/15 15:13, Dale Harvey wrote:
> A lot of people have questioned quite how hard bugzilla is to use for
> new contributors, while I fully agree that github issues are nowhere
> near powerful enough to be used on the scale that we require across dev
> / qa / release management / sheriffing etc it is pretty hard to
> overstate quite how much of a barrier bugzilla (and similiarly jira) are
> for new contributors. Dietrich and I have both spent quite a few years
> mentoring first time student contributors in various programs, along
> with experience from other open source projects and contribution
> programs I most definitely agree if we can ramp people up via github
> issues then it will be a vastly easier process.

It would be extremely useful (at least to the BMO team, I'm sure) if you
were able to spend a little time documenting the problems these
contributors have hit. Bugzilla is used across the project and I'm sure
we're all keen to see more people involved everywhere - if you have data
about the things people most often find problematic, that should be
addressed, whether you start using Github issues or not.

Gerv

[Gervase Markham]

On 07/08/15 15:13, Dale Harvey wrote:

> A lot of people have questioned quite how hard bugzilla is to use for
> new contributors, while I fully agree that github issues are nowhere
> near powerful enough to be used on the scale that we require across dev
> / qa / release management / sheriffing etc it is pretty hard to
> overstate quite how much of a barrier bugzilla (and similiarly jira) are
> for new contributors. Dietrich and I have both spent quite a few years
> mentoring first time student contributors in various programs, along
> with experience from other open source projects and contribution
> programs I most definitely agree if we can ramp people up via github
> issues then it will be a vastly easier process.

[Gervase Markham]

On 07/08/15 15:13, Dale Harvey wrote:

> A lot of people have questioned quite how hard bugzilla is to use for
> new contributors, while I fully agree that github issues are nowhere
> near powerful enough to be used on the scale that we require across dev
> / qa / release management / sheriffing etc it is pretty hard to
> overstate quite how much of a barrier bugzilla (and similiarly jira) are
> for new contributors. Dietrich and I have both spent quite a few years
> mentoring first time student contributors in various programs, along
> with experience from other open source projects and contribution
> programs I most definitely agree if we can ramp people up via github
> issues then it will be a vastly easier process.