On 26 Oct 2015, at 22:23, Nick Kew <n...@webthing.com> wrote:
> On Mon, 26 Oct 2015 09:51:43 -0700
> Jacob Champion <champio...@gmail.com> wrote:
> 
>> I'd rather not feel like I'm just annoying dev@ until you submit my 
>> stuff -- I want to *talk* about it, and improve the server.
> 
> That may not be easy.  You need to find someone who'll be interested in an 
> idea or patch, and has the time to review it.
> Plus, the community as a whole to agree it's a good idea, or at least not 
> actively oppose it.
> 
> I wonder if workflow would be improved if we had named maintainers for 
> particular parts of the codebase - for example individual modules?  Not 
> necessarily to do all the work, but to take primary responsibility to see 
> that your ideas don't just fall through the gaps and get ignored?

How does the word “sponsor” sound?

Someone who encourages and champions the development activity around a 
particular feature (and is also very welcome to contribute). The existing and 
more formal mechanisms for approving commits seem to work fine as a way of 
controlling the quality of code.


Improving the workflow means, to me, coaching and leadership, and different 
kinds of code review. Someone who isn't very good at C (like me) might well 
want to make a code contribution but not be sure how. I saw recently how much 
perseverance Yingqi Lu put in towards getting SO_REUSEPORT support into trunk 
and then into 2.4.17 – and that's great. It's unfortunate that the same 
perseverance also offers a lesson about the kind of barriers that a would-be 
contributor might encounter.

So, sponsorship can be about encouraging participation and progress. I'm 
imagining someone who rarely has to settle a decision – those should stay 
consensual and democratic - but often leads discussions and moves things on.

Comments very welcome.


-- 
Tim Bannister – is...@c8h10n4o2.org.uk

Reply via email to