Re: The end of an era, and the dawn of a new one

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 <[email protected]> wrote:
>
> On 09/12/2012, at 10:53 PM, Manuel M T Chakravarty wrote:
>
>> Ian Lynagh <[email protected]>:
>>> 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
> [email protected]
> http://www.haskell.org/mailman/listinfo/cvs-ghc