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
