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 <d...@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 <s...@dague.net <javascript:;>> > wrote: > > > > > On 11/25/2015 03:22 PM, Shamail wrote: > > > > Hi, > > > > > > > >> On Nov 25, 2015, at 11:05 PM, Doug Hellmann <d...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- ~sean
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev