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