Open Stack

Being successful at your first patch for most people means that their first
effort is different than an a regular patch.

Identifying abandoned work more quickly is good. It doesn't help the first
timer.

Tagging low hanging fruit for first timers I like. I'm recommending we add
a mentor as part of the idea, so the project mentor is responsible for the
work and the first timer learning.

On Monday, November 30, 2015, Doug Hellmann <doug at doughellmann.com> wrote:

> Excerpts from sean roberts's message of 2015-11-30 07:57:54 -0800:
> > How about:
> > First timers assign a bug to a mentor and the mentor takes responsibility
> > for the first timer learning from the bug to completion.
>
> That would mean the learning process is different from what we want the
> regular process to be.
>
> If the problem is identifying "In Progress" bugs that are actually not
> being worked on, then let's figure out a way to make that easier.
> sdague's point about the auto-abandon process may help. We could query
> gerrit for "stale" reviews that would have met the old abandon
> requirements and that refer to bugs, for example. Using that
> information, someone could follow-up with the patch owner to see if it
> is actually abandoned, before changing the bug status or encouraging the
> owner to abandon the patch.
>
> >
> > Per project, a few people volunteer themselves as mentors. As easy as
> > responding to [project][mentor] emails.
> >
> > On Monday, November 30, 2015, Sean Dague <sean at dague.net <javascript:;>>
> wrote:
> >
> > > On 11/25/2015 03:22 PM, Shamail wrote:
> > > > Hi,
> > > >
> > > >> On Nov 25, 2015, at 11:05 PM, Doug Hellmann <doug at doughellmann.com
> <javascript:;>
> > > <javascript:;>> wrote:
> > > >>
> > > >> Excerpts from Shamail Tahir's message of 2015-11-25 09:15:54 -0500:
> > > >>> Hi everyone,
> > > >>>
> > > >>> Andrew Mitry recently shared a medium post[1] by Kent C. Dobbs
> which
> > > >>> discusses how one open-source project is encouraging contributions
> by
> > > new
> > > >>> open-source contributors through a combination of a special tag
> (which
> > > is
> > > >>> associated with work that is needed but can only be completed by
> > > someone
> > > >>> who is a first-time contributor) and helpful comments in the review
> > > phase
> > > >>> to ensure the contribution(s) eventually get merged.
> > > >>>
> > > >>> While reading the article, I immediately thought about our
> > > >>> low-hanging-fruit bug tag which is used for a very similar purpose
> in
> > > "bug
> > > >>> fixing" section of  the "how to contribute" page[2].  The
> > > low-hanging-fruit
> > > >>> tag is used to identify items that are generally suitable for
> > > first-time or
> > > >>> beginner contributors but, in reality, anyone can pick them up.
> > > >>>
> > > >>> I wanted to propose a new tag (or even changing the, existing,
> > > low-hanging
> > > >>> fruit tag) that would identify items that we are reserving for
> > > first-time
> > > >>> OpenStack contributors (e.g. a patch-set for the item submitted by
> > > someone
> > > >>> who is not a first time contributor would be rejected)... The same
> > > article
> > > >>> that Andrew shared mentions using an "up-for-grabs" tag which also
> > > >>> populates the items at up-for-grabs[3] (a site where people
> looking to
> > > >>> start working on open-source projects see entry-level items from
> > > multiple
> > > >>> projects).  If we move forward with an exclusive tag for
> first-timers
> > > then
> > > >>> it would be nice if we could use the up-for-grabs tag so that
> OpenStack
> > > >>> also shows up on the list too.  Please let me know if this change
> > > should be
> > > >>> proposed elsewhere, the tags are maintained in launchpad and the
> wiki I
> > > >>> found related to bug tags[4] didn't indicate a procedure for
> > > submitting a
> > > >>> change proposal.
> > > >>
> > > >> I like the idea of making bugs suitable for first-timers more
> > > >> discoverable. I'm not sure we need to *reserve* any bugs for any
> class
> > > >> of contributor. What benefit do you think that provides?
> > > > I would have to defer to additional feedback here...
> > > >
> > > > My own perspective from when I was doing my first contribution is
> that
> > > it was hard to find active "low-hanging-fruit" items.  Most were
> already
> > > work-in-progress or assigned.
> > >
> > > This was a direct consequence of us dropping the auto-abandoning of old
> > > code reviews in gerrit. When a review is abandoned the bug is flipped
> > > back to New instead of In Progress.
> > >
> > > I found quite often people go and gobble up bugs assigning them to
> > > themselves, but don't make real progress on them. Then new contributors
> > > show up, and don't work on any of those issues because our tools say
> > > someone is already on top of it.
> > >
> > >         -Sean
> > >
> > > --
> > > Sean Dague
> > > http://dague.net
> > >
> > >
> __________________________________________________________________________
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> >
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
~sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151130/7a9bd5ce/attachment.html>