Ahh that is much better than my initial attempt! Safe Haskell directories added.
On 15 December 2012 00:46, Simon Peyton-Jones <simo...@microsoft.com> wrote: > 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
