Re: My responses to developers' responses

[Phil Holmes]

----- Original Message ----- 
From: <address@hidden>
To: "Devel Dev" <address@hidden>
Sent: Monday, June 25, 2012 2:23 PM
Subject: My responses to developers' responses


> Hey all,
>
> Thank you very much, Colin, for organizing these responses.
>
> I think GOP2-0 is very important, and as such I'd like to send responses 
> to certain excerpts from other people's emails.
>
> DevC
>
> > There's a similar problem with trying to recruit new contributors.
> > Person 41 says "hey guys, it's easy to help!  here's a link to get you
> > started", then person 15 immediately says "no wait, it's too hard.
> > Don't get involved unless somebody will help you".  And then person 15
> > and 94 start arguing about something else, so even if somebody still
> > wanted to help out, the argument would drive them away anyway.  But
> > just like the website problem, it seems that nobody is saying "yes, we
> > should have new contributors, so I will help 1 person get involved and
> > take responsibility for giving that 1 person a fair chance to
> > contribute".
>
> I agree.  I do not believe that saying "it's too hard" is a good solution. 
> I am more than willing to help people this way - I am officially naming 
> myself as "New Contributor Czar" and will propose a patch in an hour that 
> advertises this on the website.

I think "Frog meister" is the official term.

> > The third reason is the patch-handling setup.  There have been a few
> > times that some documentation needed a little edit or tweak here or
> > there, but I just couldn't be bothered to make a new branch, do the
> > edit, upload to rietveld, wait a few days, then push that branch to
> > staging.
>
> I do fixes like this all the time w/o the full review (i.e. the pondings 
> column).  Everyone trusts you - if it's truly a minor tweak, go for it.

I think James and I both rarely create new branches.  We make a change, 
commit and create a patch (in my case with lily-git) save the patch for 
future use and then reset the git repo.  That way we don't forget which 
branch has which changes.  I think this is an easier system for new 
cotributors.

--
Phil Holmes