David Terei <davidte...@gmail.com>: > 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).
I edited it a bit. Weren't there some people who volunteered as performance tsars? I still think the directory to maintainer mapping makes no sense. Manuel > 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 _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
