Thanks to David for making a start. I have re-done the page based on his work. http://hackage.haskell.org/trac/ghc/wiki/Contributors
Please look! I have begun with a statement about what being an "owner" means; please help refine it. Also I'm sure I have missed out areas that should be listed. Please edit. David: pls add the Safe Haskell directories. General opinions? Simon | -----Original Message----- | From: cvs-ghc-boun...@haskell.org [mailto:cvs-ghc-boun...@haskell.org] | On Behalf Of David Terei | Sent: 12 December 2012 23:14 | To: Ben Lippmeier | Cc: Ian Lynagh; cvs-ghc@haskell.org; Manuel M T Chakravarty | Subject: 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 <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