So I had a go at updating the wiki page to reflect ownership / tsar
status / maintainers.

http://hackage.haskell.org/trac/ghc/wiki/Contributors

This page will probably need to change when reach a conclusion of how
we want to frame this responsibility (i.e., owners, maintainers,
tsars).

The list of people is very light right now as I only put down people
who had said they would take ownership of a task. (although I did make
assumptions for Ian, Simon PJ & Simon M).

On 9 December 2012 16:53, Ben Lippmeier <b...@ouroborus.net> wrote:
>
> On 09/12/2012, at 10:53 PM, Manuel M T Chakravarty wrote:
>
>> Ian Lynagh <i...@well-typed.com>:
>>> On Thu, Dec 06, 2012 at 12:32:05PM +0000, Simon Peyton-Jones wrote:
>>>> (Narrowing to cvs-ghc for now.)
>>>>
>>>> Speaking for myself, I would welcome a code-ownership model along the 
>>>> lines that Ben suggests. If it works well it would
>>>> a) spread the load
>>>> b) broaden a genuine sense of ownership
>>>> c) because of (a) and (b), perhaps encourage more people to participate
>>>>
>>>> What do others think?
>>>
>>> "owner" is a very strong word: I think other projects have had problems
>>> where e.g. owners have found themselves without time to deal with
>>> patches submitted, but have been unwilling to let anyone else touch
>>> "their" code.
>>>
>>> Perhaps we could have "maintainers" instead?
>>
>> I agree with Ian here.
>>
>> Code ownership is not necessarily a Good Thing. In fact, it is often 
>> discouraged in modern approaches to software engineering. Why? Because it 
>> creates a barrier for the non-owners to contribute to a code base, 
>> especially if we would start to introduce procedures such as an obligation 
>> for the owner to review all patches to *their* code base.
>
>  I agree that having a "Ownership" model may increase the barrier to new 
> contributors submitting drive-by patches, but at the same time it reduces the 
> barrier to the owner performing more wide ranging changes and refactorings.
>
> If I'm a drive-by contributor or assigned maintainer, then I'm probably not 
> going to spend a week of my own time refactoring, documenting, and cleaning 
> up all the native code generators, because it's not my project. However, if I 
> were to make a conscious decision to assume responsibility for that code for 
> (say) a year, I'd go though and clean it all up. Maintenance is largely a 
> thankless task because it doesn't lead to a sexy feature or support for a new 
> platform. It does improve the overall health of the project, though. Having 
> successive people assume ownership, and then going though and auditing all 
> the code would be even better.
>
>
>> This is particularly awkward in an open source project. If somebody is busy 
>> (or on holidays) for a month, nobody can push patches that touch that code.
>
> I don't think going to an Ownership model need prevent people with accounts 
> on d.h.o continuing to change whatever code they need to. If I were to assume 
> responsibility for some code I'm not going to require Simon(s) or Johan to 
> submit patches to me for review. It's true that some contributed patches may 
> languish on the trac for a few weeks, but that happens anyway.
>
>
>> I like the "Tsar" idea that SPJ started with the Performance Tsar(s). 
>> Instead of assigning ownership of code (like in a land grab), let's define 
>> areas of responsibility. Many of these responsibilities (like performance) 
>> will touch on a cross section of the code base.
>
>
> My worry is that having a responsibility without a corresponding asset feels 
> more like a job than a fun thing to do. The "asset" here is more of an 
> emotional construct than a physical one -- a sense of "this is mine to look 
> after".
>
> Code maintenance isn't fun, and given the choice I'd prefer to work on my own 
> projects than documenting someone else's code. If you say "you can be 
> responsible for the performance of GHC" that's a fairly nebulous concept, but 
> if you say "this code is yours for a year, look after it", then it gives the 
> owner some immediate, well defined, concrete goals.
>
> It's the tragedy of the commons. Without a sense of ownership, people won't 
> take real responsibility.
>
> Ben.
>
>
> _______________________________________________
> Cvs-ghc mailing list
> Cvs-ghc@haskell.org
> http://www.haskell.org/mailman/listinfo/cvs-ghc

_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc

Reply via email to