good first bug levels

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

good first bug levels

Alexander Surkov
Hi.

I think it should be useful for new contributors if we were
catheterized good first bugs by required skills. Usually when
contributor fixes couple trivial bugs he wants to try something more
interesting and complicated. As a mentor I don't always have an answer
what he could try next. If I had an option to provide a level for good
first bug then it solves the problem.

I think of 3 levels:
level0: trivial bugs like methods renaming and removing
level1: simple bugs requiring code logic changes, might require automated tests
level2: still simple bugs requiring code logic changes but needs some
investigations

The following whiteboard status syntax could be used for that
[good-first-bug][mentor=email][lang=lang][level0]. Does it sound
reasonable?

Thanks.
Alex.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: good first bug levels

Justin Lebar-3
On Fri, Mar 23, 2012 at 2:20 AM, Alexander Surkov
<[hidden email]> wrote:

> Hi.
>
> I think it should be useful for new contributors if we were
> catheterized good first bugs by required skills. Usually when
> contributor fixes couple trivial bugs he wants to try something more
> interesting and complicated. As a mentor I don't always have an answer
> what he could try next. If I had an option to provide a level for good
> first bug then it solves the problem.
>
> I think of 3 levels:
> level0: trivial bugs like methods renaming and removing
> level1: simple bugs requiring code logic changes, might require automated tests
> level2: still simple bugs requiring code logic changes but needs some
> investigations
>
> The following whiteboard status syntax could be used for that
> [good-first-bug][mentor=email][lang=lang][level0]. Does it sound
> reasonable?

Personally, I'm wary of adding even more annotations to our
good-first-bugs, if only because none of our current annotations is
applied systematically.  For example, some people say to leave off the
[good-first-bug] tag and use only [mentor].  And then some people (for
example, me) leave off the [lang] tag.  The less-consistently these
annotations are applied, the less useful they are.

I don't think it's unreasonable for a new contributor to scan through
a buglist and figure out which ones look like trivial changes versus
which ones look harder.  Where a contributor can't do that, they can
always ask on irc...

Do you often find yourself in a position of being unable to roughly
evaluate the level of a [mentor] bug from its summary?  If so, perhaps
we should try to get people to write better bug summaries.  :)

-Justin
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: good first bug levels

Mounir Lamouri-3
On 03/23/2012 02:28 PM, Justin Lebar wrote:
> For example, some people say to leave off the
> [good-first-bug] tag and use only [mentor].

I thought the idea behind mentored bug was that "good first bug" were a
bad name and instead it was better to say "I will mentor you for this
bug". The bug can be very trivial or a bit harder. At least, I tend to
mark myself as mentoring bugs when I know I will not have time to fix it
anytime soon but I could help even if it's not easy...

--
Mounir
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: good first bug levels

Anthony Hughes-3
In reply to this post by Justin Lebar-3
On 03/23/2012 06:28 AM, Justin Lebar wrote:

> On Fri, Mar 23, 2012 at 2:20 AM, Alexander Surkov
> <[hidden email]>  wrote:
>> Hi.
>>
>> I think it should be useful for new contributors if we were
>> catheterized good first bugs by required skills. Usually when
>> contributor fixes couple trivial bugs he wants to try something more
>> interesting and complicated. As a mentor I don't always have an answer
>> what he could try next. If I had an option to provide a level for good
>> first bug then it solves the problem.
>>
>> I think of 3 levels:
>> level0: trivial bugs like methods renaming and removing
>> level1: simple bugs requiring code logic changes, might require automated tests
>> level2: still simple bugs requiring code logic changes but needs some
>> investigations
>>
>> The following whiteboard status syntax could be used for that
>> [good-first-bug][mentor=email][lang=lang][level0]. Does it sound
>> reasonable?
> Personally, I'm wary of adding even more annotations to our
> good-first-bugs, if only because none of our current annotations is
> applied systematically.  For example, some people say to leave off the
> [good-first-bug] tag and use only [mentor].  And then some people (for
> example, me) leave off the [lang] tag.  The less-consistently these
> annotations are applied, the less useful they are.
>
> I don't think it's unreasonable for a new contributor to scan through
> a buglist and figure out which ones look like trivial changes versus
> which ones look harder.  Where a contributor can't do that, they can
> always ask on irc...
>
> Do you often find yourself in a position of being unable to roughly
> evaluate the level of a [mentor] bug from its summary?  If so, perhaps
> we should try to get people to write better bug summaries.  :)
>
> -Justin
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
Perhaps a good practice would be to add that level of detail you are
seeking by way of bug comment when adding the [good first bug]
whiteboard tag. Adding another whiteboard tag just adds another level of
ambiguity that a new contributor has to learn.

If finding "what's next" for a new contributor is a common problem then
maybe that could be solved via whiteboard tagging, but I'd like to find
another way if possible.

If it ultimately came down to using whiteboard tags, I would suggest
altering the existing tag and not adding another tag:
  [good first bug]
  [good second bug]
  [ good third bug]

--
Anthony Hughes
Quality Engineer, Mozilla

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: good first bug levels

Josh Matthews-4
In reply to this post by Alexander Surkov
For the record, I'd like to clear up the benefits of the annotations
that I use from the point of my of my Bugs Ahoy tool that will be going
live on mozilla.org soon (http://www.joshmatthews.net/bugsahoy/):

* mentor=name - causes the bug to show up in Bugs Ahoy, full stop
* lang=[py|js|c++|xul|css] - allows the bug to be filtered by language on BA

The "good first bug" annotation has no impact, except that I watch the
RSS feed of bugs with that annotation and try to add a mentor tag to as
many of them as possible.

Cheers,
Josh

On 12-03-23 9:28 AM, Justin Lebar wrote:

> On Fri, Mar 23, 2012 at 2:20 AM, Alexander Surkov
> <[hidden email]>  wrote:
>> Hi.
>>
>> I think it should be useful for new contributors if we were
>> catheterized good first bugs by required skills. Usually when
>> contributor fixes couple trivial bugs he wants to try something more
>> interesting and complicated. As a mentor I don't always have an answer
>> what he could try next. If I had an option to provide a level for good
>> first bug then it solves the problem.
>>
>> I think of 3 levels:
>> level0: trivial bugs like methods renaming and removing
>> level1: simple bugs requiring code logic changes, might require automated tests
>> level2: still simple bugs requiring code logic changes but needs some
>> investigations
>>
>> The following whiteboard status syntax could be used for that
>> [good-first-bug][mentor=email][lang=lang][level0]. Does it sound
>> reasonable?
>
> Personally, I'm wary of adding even more annotations to our
> good-first-bugs, if only because none of our current annotations is
> applied systematically.  For example, some people say to leave off the
> [good-first-bug] tag and use only [mentor].  And then some people (for
> example, me) leave off the [lang] tag.  The less-consistently these
> annotations are applied, the less useful they are.
>
> I don't think it's unreasonable for a new contributor to scan through
> a buglist and figure out which ones look like trivial changes versus
> which ones look harder.  Where a contributor can't do that, they can
> always ask on irc...
>
> Do you often find yourself in a position of being unable to roughly
> evaluate the level of a [mentor] bug from its summary?  If so, perhaps
> we should try to get people to write better bug summaries.  :)
>
> -Justin

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: good first bug levels

Josh Matthews-4
In reply to this post by Justin Lebar-3
On 12-03-23 10:09 AM, Mounir Lamouri wrote:

> On 03/23/2012 02:28 PM, Justin Lebar wrote:
>> For example, some people say to leave off the
>> [good-first-bug] tag and use only [mentor].
>
> I thought the idea behind mentored bug was that "good first bug" were a
> bad name and instead it was better to say "I will mentor you for this
> bug". The bug can be very trivial or a bit harder. At least, I tend to
> mark myself as mentoring bugs when I know I will not have time to fix it
> anytime soon but I could help even if it's not easy...
>
> --
> Mounir

This is the viewpoint that I have been promoting. The mentor tag is
strictly more useful than [good first bug] since it has a name attached
to it. In my experience, it's often fairly easy to distinguish the more
complex bugs from the trivial ones based on the subject - the typical
beginner ones have names like "inline uses of nsIFoo" or "change X to Y".

Cheers,
Josh
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: good first bug levels

Kartikaya Gupta-6
In reply to this post by Alexander Surkov
(This is somewhat tangential to the original topic). Something I've
noticed when trying to contribute to other large open-source projects
before is that even if there's something like a "good first bug" list,
it's hard for a newcomer to know where in the code to fix it. (i.e. it
might be a one-line fix but knowing where to put the one line is tricky).

I've often thought that it would be good to have "walkthrough bugs" -
ones that we already know exactly how to fix, and can be used to help
new contributors get their feet wet without risk of failure. There would
be a wiki page with basically step-by-step instructions on how to fix
the bug (down to the level of "open file foo.cpp and insert the
following code into function bar"), along with details about the code
flow (function bar is called from function baz over in qux.cpp which is
interesting because...), module organization, etc.. Ideally the patch
they are walked through has a visible impact on their build, so they get
that feeling of satisfaction from having successfully hacked their
browser. That feeling is ultimately what's going to bring them back to
do it again and again.

Obviously patches for these "walkthrough bugs" should never actually be
landed or they lose their value for future contributors, so maybe they
shouldn't be real bugs but just customizations or something to that
effect. If we have a bunch of these that touch different parts of the
codebase, then it allows new contributors to learn different parts of
the code and therefore warm up to tackling real bugs in those components.

Thoughts?

Cheers,
kats

On 12-03-23 02:20 , Alexander Surkov wrote:

> Hi.
>
> I think it should be useful for new contributors if we were
> catheterized good first bugs by required skills. Usually when
> contributor fixes couple trivial bugs he wants to try something more
> interesting and complicated. As a mentor I don't always have an answer
> what he could try next. If I had an option to provide a level for good
> first bug then it solves the problem.
>
> I think of 3 levels:
> level0: trivial bugs like methods renaming and removing
> level1: simple bugs requiring code logic changes, might require automated tests
> level2: still simple bugs requiring code logic changes but needs some
> investigations
>
> The following whiteboard status syntax could be used for that
> [good-first-bug][mentor=email][lang=lang][level0]. Does it sound
> reasonable?
>
> Thanks.
> Alex.

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: good first bug levels

Ted Mielczarek-2
On Fri, Mar 23, 2012 at 11:38 AM, Kartikaya Gupta <[hidden email]> wrote:

> (This is somewhat tangential to the original topic). Something I've noticed
> when trying to contribute to other large open-source projects before is that
> even if there's something like a "good first bug" list, it's hard for a
> newcomer to know where in the code to fix it. (i.e. it might be a one-line
> fix but knowing where to put the one line is tricky).
>
> I've often thought that it would be good to have "walkthrough bugs" - ones
> that we already know exactly how to fix, and can be used to help new
> contributors get their feet wet without risk of failure. There would be a
> wiki page with basically step-by-step instructions on how to fix the bug
> (down to the level of "open file foo.cpp and insert the following code into
> function bar"), along with details about the code flow (function bar is
> called from function baz over in qux.cpp which is interesting because...),
> module organization, etc.. Ideally the patch they are walked through has a
> visible impact on their build, so they get that feeling of satisfaction from
> having successfully hacked their browser. That feeling is ultimately what's
> going to bring them back to do it again and again.
>
> Obviously patches for these "walkthrough bugs" should never actually be
> landed or they lose their value for future contributors, so maybe they
> shouldn't be real bugs but just customizations or something to that effect.
> If we have a bunch of these that touch different parts of the codebase, then
> it allows new contributors to learn different parts of the code and
> therefore warm up to tackling real bugs in those components.
>
> Thoughts?

Dave Humphrey has used techniques like this before, fixing an
already-fixed bug just to go through the steps of diagnosing and
writing and testing a patch. I'm sure he could relate his experiences.

One thing to consider is that while this might be a learning
experience, there's probably a much more powerful learning experience
in figuring all those steps out yourself (even if you have much
hand-holding), because you actually *accomplished* something, and got
a patch landed in the source. There's just no replicating that
feeling! I think the mentoring process is the best solution here. An
experienced developer can give new contributors the benefit of
accumulated knowledge about where to look in the code base, and how to
navigate the Bugzilla/review process, while still having the
contributor do useful work.

-Ted
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: good first bug levels

Josh Matthews-4
In reply to this post by Kartikaya Gupta-6
One thing I've been pushing is reminding mentors to drop MXR links to
the relevant source files when marking bugs as mentored. These should be
the bare minimum we're providing; vague summaries that are full of
inside knowledge and jargon are not helpful for people just seeing the
code and BMO for the very first time.

Cheers,
Josh

On 12-03-23 11:38 AM, Kartikaya Gupta wrote:

> (This is somewhat tangential to the original topic). Something I've
> noticed when trying to contribute to other large open-source projects
> before is that even if there's something like a "good first bug" list,
> it's hard for a newcomer to know where in the code to fix it. (i.e. it
> might be a one-line fix but knowing where to put the one line is tricky).
>
> I've often thought that it would be good to have "walkthrough bugs" -
> ones that we already know exactly how to fix, and can be used to help
> new contributors get their feet wet without risk of failure. There would
> be a wiki page with basically step-by-step instructions on how to fix
> the bug (down to the level of "open file foo.cpp and insert the
> following code into function bar"), along with details about the code
> flow (function bar is called from function baz over in qux.cpp which is
> interesting because...), module organization, etc.. Ideally the patch
> they are walked through has a visible impact on their build, so they get
> that feeling of satisfaction from having successfully hacked their
> browser. That feeling is ultimately what's going to bring them back to
> do it again and again.
>
> Obviously patches for these "walkthrough bugs" should never actually be
> landed or they lose their value for future contributors, so maybe they
> shouldn't be real bugs but just customizations or something to that
> effect. If we have a bunch of these that touch different parts of the
> codebase, then it allows new contributors to learn different parts of
> the code and therefore warm up to tackling real bugs in those components.
>
> Thoughts?
>
> Cheers,
> kats
>
> On 12-03-23 02:20 , Alexander Surkov wrote:
>> Hi.
>>
>> I think it should be useful for new contributors if we were
>> catheterized good first bugs by required skills. Usually when
>> contributor fixes couple trivial bugs he wants to try something more
>> interesting and complicated. As a mentor I don't always have an answer
>> what he could try next. If I had an option to provide a level for good
>> first bug then it solves the problem.
>>
>> I think of 3 levels:
>> level0: trivial bugs like methods renaming and removing
>> level1: simple bugs requiring code logic changes, might require
>> automated tests
>> level2: still simple bugs requiring code logic changes but needs some
>> investigations
>>
>> The following whiteboard status syntax could be used for that
>> [good-first-bug][mentor=email][lang=lang][level0]. Does it sound
>> reasonable?
>>
>> Thanks.
>> Alex.
>

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: good first bug levels

David Rajchenbach-Teller-2
In reply to this post by Ted Mielczarek-2
I agree with Ted: it is an interesting suggestion, but being fed a
walkthrough bug does not quite the same thing as going through the
actual process of finding out where the issue comes from, finding out
who to discuss it with, and getting a patch finally landed.

Having had some experience helping around #introduction, #extdev, etc. I
personally believe that mentoring is a much better solution.

Cheers,
 David

On 3/23/12 4:49 PM, Ted Mielczarek wrote:

>> Obviously patches for these "walkthrough bugs" should never actually be
>> landed or they lose their value for future contributors, so maybe they
>> shouldn't be real bugs but just customizations or something to that effect.
>> If we have a bunch of these that touch different parts of the codebase, then
>> it allows new contributors to learn different parts of the code and
>> therefore warm up to tackling real bugs in those components.
>>
>> Thoughts?
>
> Dave Humphrey has used techniques like this before, fixing an
> already-fixed bug just to go through the steps of diagnosing and
> writing and testing a patch. I'm sure he could relate his experiences.
>
> One thing to consider is that while this might be a learning
> experience, there's probably a much more powerful learning experience
> in figuring all those steps out yourself (even if you have much
> hand-holding), because you actually *accomplished* something, and got
> a patch landed in the source. There's just no replicating that
> feeling! I think the mentoring process is the best solution here. An
> experienced developer can give new contributors the benefit of
> accumulated knowledge about where to look in the code base, and how to
> navigate the Bugzilla/review process, while still having the
> contributor do useful work.
>
> -Ted
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning

--
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

signature.asc (498 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: good first bug levels

Edmund-4
In reply to this post by Alexander Surkov
Alexander Surkov wrote:

> Hi.
>
> I think it should be useful for new contributors if we were
> catheterized good first bugs by required skills. Usually when
> contributor fixes couple trivial bugs he wants to try something more
> interesting and complicated. As a mentor I don't always have an answer
> what he could try next. If I had an option to provide a level for good
> first bug then it solves the problem.
>
> I think of 3 levels:

Hi,

Here's a topic close to my heart.  I'm a relatively new contributor
(well, 2nd year w/ SeaMonkey and have contributed to a few patches
for Core et. al) and I've been looking at [good first bugs].

I"m still doing [good first bugs] because I'm still not very
fluent in the code.

Here's my take on this.  I want to contribute. Here's the
process I use.

1) I see a 'good first bug' and I read the description.

2) If the bug description isn't clear, then the first thing that
    pops in my mind is "I don't understand this." (This is my
    most regular thought.)  Next question is, "Should I do this?"
    "It sounds difficult.  Maybe I'm dumb. Maybe I should find a
    different bug." (Again. My most frequent response.)
    Select a new bug and goto #1.

3) If the bug description is clear, then the first thing that
    pops in my mind is "where in the code is this going to be?"

4) Is there some pointer in the comments?

   4a) Yes. Figure out from the comments what I need to change.

   4b) No.  "Ummm.. should I send an e-mail or go online to
    talk to the mentor? Or should I go find a different bug?"

      4b-i) IRC: ping mentor. or email mentor (if cannot IRC)
            wait for response.

            4b-i-a) No response? Select new bug. Goto 1)
            4b-i-b) Mentor responds. Discuss.

      4b-ii) Find a different bug.  Select new bug. Goto 1)

I think the first thing that will help is at least a possible
pinpoint as to where the code is.  That will help the real new
contributors not familiar with the code.  Then if the contributor
looks at the code and is unclear as how to proceed, that's when
the mentor comes in.  (By 'comes in', I mean that's when the
contributor contacts the mentor via e-mail or irc, but should
realize that there's a chance that the contributor's TZ is
far off from the regular TZ that most mentors are in.) (Case
in point. Me.)

So now that the contributor knows where the code is.  What does
he/she do next?  The mentor clarifies what generally should be
  done and let the contributor try and figure it out what code
needs to be changed.

The end result is that the contributor finds out what he/she
needs to know about the bug and then tries to fix it.  So
having 'levels' isn't quite relevant to the overall task at
hand.  To me, it would frustrate me even more.  "What?  I've
been contributing for so long and I'm still stuck on level 0?"
(Note: Actually, this can be applied to gfbs anyway. i.e. "Am
I dumb? I'm still doing gfbs?")

That's my 'new' contributor $0.02.

Edmund









_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: good first bug levels

Alexander Surkov
> So
> having 'levels' isn't quite relevant to the overall task at
> hand.  To me, it would frustrate me even more.  "What?  I've
> been contributing for so long and I'm still stuck on level 0?"
> (Note: Actually, this can be applied to gfbs anyway. i.e. "Am
> I dumb? I'm still doing gfbs?")

Then level must be not a good term if it makes think this way. By
level I meant a level of the bug and no way a level of the
contributor. So level 0 meant a 10 minutes bug fix, just a code
cleaning up, a thing that all contributors do from time to time.

I wanted to make the process of finding the bug easier. Providing a
hint how the bug might be complicated/trivial should save the
contributor's time allowing him to not read a bug description and not
looking into code.

Thank you.
Alex.


On Sat, Mar 24, 2012 at 12:51 PM, Ed <[hidden email]> wrote:

> Alexander Surkov wrote:
>>
>> Hi.
>>
>> I think it should be useful for new contributors if we were
>> catheterized good first bugs by required skills. Usually when
>> contributor fixes couple trivial bugs he wants to try something more
>> interesting and complicated. As a mentor I don't always have an answer
>> what he could try next. If I had an option to provide a level for good
>> first bug then it solves the problem.
>>
>> I think of 3 levels:
>
>
> Hi,
>
> Here's a topic close to my heart.  I'm a relatively new contributor
> (well, 2nd year w/ SeaMonkey and have contributed to a few patches
> for Core et. al) and I've been looking at [good first bugs].
>
> I"m still doing [good first bugs] because I'm still not very
> fluent in the code.
>
> Here's my take on this.  I want to contribute. Here's the
> process I use.
>
> 1) I see a 'good first bug' and I read the description.
>
> 2) If the bug description isn't clear, then the first thing that
>   pops in my mind is "I don't understand this." (This is my
>   most regular thought.)  Next question is, "Should I do this?"
>   "It sounds difficult.  Maybe I'm dumb. Maybe I should find a
>   different bug." (Again. My most frequent response.)
>   Select a new bug and goto #1.
>
> 3) If the bug description is clear, then the first thing that
>   pops in my mind is "where in the code is this going to be?"
>
> 4) Is there some pointer in the comments?
>
>  4a) Yes. Figure out from the comments what I need to change.
>
>  4b) No.  "Ummm.. should I send an e-mail or go online to
>   talk to the mentor? Or should I go find a different bug?"
>
>     4b-i) IRC: ping mentor. or email mentor (if cannot IRC)
>           wait for response.
>
>           4b-i-a) No response? Select new bug. Goto 1)
>           4b-i-b) Mentor responds. Discuss.
>
>     4b-ii) Find a different bug.  Select new bug. Goto 1)
>
> I think the first thing that will help is at least a possible
> pinpoint as to where the code is.  That will help the real new
> contributors not familiar with the code.  Then if the contributor
> looks at the code and is unclear as how to proceed, that's when
> the mentor comes in.  (By 'comes in', I mean that's when the
> contributor contacts the mentor via e-mail or irc, but should
> realize that there's a chance that the contributor's TZ is
> far off from the regular TZ that most mentors are in.) (Case
> in point. Me.)
>
> So now that the contributor knows where the code is.  What does
> he/she do next?  The mentor clarifies what generally should be
>  done and let the contributor try and figure it out what code
> needs to be changed.
>
> The end result is that the contributor finds out what he/she
> needs to know about the bug and then tries to fix it.  So
> having 'levels' isn't quite relevant to the overall task at
> hand.  To me, it would frustrate me even more.  "What?  I've
> been contributing for so long and I'm still stuck on level 0?"
> (Note: Actually, this can be applied to gfbs anyway. i.e. "Am
> I dumb? I'm still doing gfbs?")
>
> That's my 'new' contributor $0.02.
>
> Edmund
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: good first bug levels

Matt Brubeck-3
In reply to this post by Edmund-4
On 03/25/2012 10:48 PM, Alexander Surkov wrote:
> Then level must be not a good term if it makes think this way. By
> level I meant a level of the bug and no way a level of the
> contributor. So level 0 meant a 10 minutes bug fix, just a code
> cleaning up, a thing that all contributors do from time to time.

"Size" might be a better (more neutral) term.  ("size=small" vs
"size=large", or maybe "scale=simple" vs. "scale=complex"...)
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: good first bug levels

Kevin Brosnan-2
On Mon 26 Mar 2012 10:00:48 AM PDT, Matt Brubeck wrote:

> On 03/25/2012 10:48 PM, Alexander Surkov wrote:
>> Then level must be not a good term if it makes think this way. By
>> level I meant a level of the bug and no way a level of the
>> contributor. So level 0 meant a 10 minutes bug fix, just a code
>> cleaning up, a thing that all contributors do from time to time.
>
> "Size" might be a better (more neutral) term.  ("size=small" vs
> "size=large", or maybe "scale=simple" vs. "scale=complex"...)
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning

Do we really need more arcane data in the whiteboard? Seems something
that a good comment could cover.

Kevin
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: good first bug levels

Jeff Hammel-2
On 03/26/2012 10:48 AM, Kevin Brosnan wrote:

> On Mon 26 Mar 2012 10:00:48 AM PDT, Matt Brubeck wrote:
>> On 03/25/2012 10:48 PM, Alexander Surkov wrote:
>>> Then level must be not a good term if it makes think this way. By
>>> level I meant a level of the bug and no way a level of the
>>> contributor. So level 0 meant a 10 minutes bug fix, just a code
>>> cleaning up, a thing that all contributors do from time to time.
>> "Size" might be a better (more neutral) term.  ("size=small" vs
>> "size=large", or maybe "scale=simple" vs. "scale=complex"...)
>> _______________________________________________
>> dev-planning mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-planning
> Do we really need more arcane data in the whiteboard? Seems something
> that a good comment could cover.
>
> Kevin
>
+1. It seems like this is more easily assessed by the bug-tackler and
the mentor and has the bonus of increased communication.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: good first bug levels

Justin Dolske-2
In reply to this post by Alexander Surkov
On 3/22/12 11:20 PM, Alexander Surkov wrote:

> I think it should be useful for new contributors if we were
> catheterized good first bugs by required skills. Usually when
> contributor fixes couple trivial bugs he wants to try something more
> interesting and complicated. As a mentor I don't always have an answer
> what he could try next.

I don't think we should make [good-first-bug] more complex. Especially
because new contributors can't be expected to know or learn a nuanced
system like that. Either a "good first bug" is, or it isn't.

However, I very much _do_ agree that it would be be helpful to have a
way for newish contributors to ease into more complex work. Perhaps a
[good-second-bug] ;-). I say that jokingly, but it's about right... It
would be overkill to have hyperfine levels (eg [good-twentyth-bug]!) But
two or three levels beyond "first bugs", as you essentially suggest,
feels about right to me. If a contributor makes it that far, they're
going to be pretty well plugged into the places and tools to succeed.

[That would match my experiences with interns in the Firefox group, we
usually set them up with a series of about 3 bugs to learn how things
work, by which point they're racing off on their own.]

I wonder if it would make sense, with such a system, to add a new
"complexity" field to Bugzilla. Whiteboard tags are a bit arcane,
something like this might help?

Justin
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: good first bug levels

Alexander Surkov
I think I'm fine with good-first/second/third-bug like I'm fine with
any other option that helps the contributor to find a bug or me to do
that when I'm asked. But it seems many people think it's preferable to
provide perfect summaries and extended descriptions rather than
introduce meta information. I'm not sure how to reach an agreement to
make everybody happy. Is it a bad idea if I go with
good-second/third-bug idea for bugs I mentoring to see how it goes?

Thanks.
Alex.

On Tue, Mar 27, 2012 at 12:25 PM, Justin Dolske <[hidden email]> wrote:

> On 3/22/12 11:20 PM, Alexander Surkov wrote:
>
>> I think it should be useful for new contributors if we were
>> catheterized good first bugs by required skills. Usually when
>> contributor fixes couple trivial bugs he wants to try something more
>> interesting and complicated. As a mentor I don't always have an answer
>> what he could try next.
>
>
> I don't think we should make [good-first-bug] more complex. Especially
> because new contributors can't be expected to know or learn a nuanced system
> like that. Either a "good first bug" is, or it isn't.
>
> However, I very much _do_ agree that it would be be helpful to have a way
> for newish contributors to ease into more complex work. Perhaps a
> [good-second-bug] ;-). I say that jokingly, but it's about right... It would
> be overkill to have hyperfine levels (eg [good-twentyth-bug]!) But two or
> three levels beyond "first bugs", as you essentially suggest, feels about
> right to me. If a contributor makes it that far, they're going to be pretty
> well plugged into the places and tools to succeed.
>
> [That would match my experiences with interns in the Firefox group, we
> usually set them up with a series of about 3 bugs to learn how things work,
> by which point they're racing off on their own.]
>
> I wonder if it would make sense, with such a system, to add a new
> "complexity" field to Bugzilla. Whiteboard tags are a bit arcane, something
> like this might help?
>
> Justin
>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: good first bug levels

Nicholas Nethercote
On Mon, Mar 26, 2012 at 9:02 PM, Alexander Surkov
<[hidden email]> wrote:
> I think I'm fine with good-first/second/third-bug like I'm fine with
> any other option that helps the contributor to find a bug or me to do
> that when I'm asked. But it seems many people think it's preferable to
> provide perfect summaries and extended descriptions rather than
> introduce meta information. I'm not sure how to reach an agreement to
> make everybody happy. Is it a bad idea if I go with
> good-second/third-bug idea for bugs I mentoring to see how it goes?

Josh said upthread that "good-first-bug" is pretty much defunct,
"mentor=..." is the preferred form, and that he converts
"good-first-bug" to "mentor=..." when he notices them.  Since Josh has
written a tool that uses these annotations, I suspect his opinion
should be listened to.

As for finer-grained annotations... I'm having trouble imagining what
kind of bug I'd annotate with "good-second-bug" or "good-third-bug".
It would depend hugely on the contributor.  Also, if I were a newcomer
to a project I'd rather do 5 or 10 "good first bugs" before moving
onto more difficult things.

Overall, I'm skeptical of the notion that things would be much better
if we only had more detailed bug annotations;  I think better
descriptions in the comments (with MXR links) are much more important.

Nick
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: good first bug levels

Alexander Surkov
> Josh said upthread that "good-first-bug" is pretty much defunct,
> "mentor=..." is the preferred form,

It's pretty defunct now. But if good-second/third-bug are introduced
then these statuses should be used together like mentor means this bug
is mentoring, good-nth-bug points to bug complexity.

> As for finer-grained annotations... I'm having trouble imagining what
> kind of bug I'd annotate with "good-second-bug" or "good-third-bug".
> It would depend hugely on the contributor.

Of course they are subjective but many contributors gets back over and
over to the same module and work with same contributors. Providing a
hint for them looks useful.

>  Also, if I were a newcomer
> to a project I'd rather do 5 or 10 "good first bugs" before moving
> onto more difficult things.

That's right. And having the hint should make things easier for you to
move next.

Thanks.
Alex.

On Tue, Mar 27, 2012 at 1:23 PM, Nicholas Nethercote
<[hidden email]> wrote:

> On Mon, Mar 26, 2012 at 9:02 PM, Alexander Surkov
> <[hidden email]> wrote:
>> I think I'm fine with good-first/second/third-bug like I'm fine with
>> any other option that helps the contributor to find a bug or me to do
>> that when I'm asked. But it seems many people think it's preferable to
>> provide perfect summaries and extended descriptions rather than
>> introduce meta information. I'm not sure how to reach an agreement to
>> make everybody happy. Is it a bad idea if I go with
>> good-second/third-bug idea for bugs I mentoring to see how it goes?
>
> Josh said upthread that "good-first-bug" is pretty much defunct,
> "mentor=..." is the preferred form, and that he converts
> "good-first-bug" to "mentor=..." when he notices them.  Since Josh has
> written a tool that uses these annotations, I suspect his opinion
> should be listened to.
>
> As for finer-grained annotations... I'm having trouble imagining what
> kind of bug I'd annotate with "good-second-bug" or "good-third-bug".
> It would depend hugely on the contributor.  Also, if I were a newcomer
> to a project I'd rather do 5 or 10 "good first bugs" before moving
> onto more difficult things.
>
> Overall, I'm skeptical of the notion that things would be much better
> if we only had more detailed bug annotations;  I think better
> descriptions in the comments (with MXR links) are much more important.
>
> Nick
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning