Re: About GNOME 2.0 - The end of a dream

[Daniel Veillard <veillard redhat com>]

On Sun, Jun 17, 2001 at 05:23:43PM -0400, Miguel de Icaza wrote:
> >>>>> "Daniel" == Daniel Veillard <veillard redhat com> writes:
> 
>     >   I'm surprized Miguel went through a long mail about "we need
>     > more love" but didn't answer to the rational way I suggested to
>     > make progresses on this and avoid such problem on this
>     > issue. Sorry guys, if desagreements are not handled early, if
>     > new project are lauched without some kind of general agreement,
>     > this will never stop, this will increase as we are growing
>     > ... if we grow.
> 
> I did that because I found a few mails that began with `Fuck you
> Michael' and I saw a kind of debate that was far from being rational. 
> 
> If you point me to your mail, which at this point is burried in a pile
> of noise, I can read it and comment on it.  

    http://mail.gnome.org/archives/gnome-hackers/2001-June/msg00123.html

> But the feeling I got when I remember reading it was `Committee
> approach' not the hacker approach. 

  Well one need structure as things grow, and we are not developping
an OS where the interface between user and kernel space had been written
in stone a long time ago. So we need a common understanding of the framework
what's been worked on, how it's gonna fit in the infrastructure and when
it will be ready.

-------------- excerpt from my initial mail ------------------------------
The kind of process I know helps avoiding those situation is the following:
   - suppose we decide to roll out ProjectX (this can be a release, a new
     library, etc...) then if this is to be part of the Gnome platform
     in the end this should be announced and discuted *before* starting
     the project (the Gnome-2.0 meeting at Guadec is oen good example).
   - from that initial discussion you define:
      - the requirement of the project
      - the roadmap
   - people interested should be able to join independantly of their
     employeer.
   - the code have to be developped publicly.
   - if there is a need to change the requirement or the roadmap, this
     has at least to be announced to the global channel again (the foundation
     list sounds the right place), so that people can record objections
     an if possible adapt the change in their own project if this impact
     them
   - before considering the ProjectX finished and starting the deployement
     (say 1.0) the current state of the project should be posted to the
     general list to allow people to make a last pass.
--------------------------------------------

  Let's examine what dropping any of 1/ - 6/ points really means:
    1/ no announcement or discussion of the project before it being
       started => you get surprises at the last minute, divergent efforts
       and the result may not fit the need of the whole project
    2/ if you don't set requirement before hand, the project has less chances
       to actually build something useful to the whole project
       if you don't put up a raodmap (estimate) first it's also impossible
       to guess when teh users should start using the new stuff and do the
       minimal mount of planning
    3/ well GNOME is an open project and I think this is mandatory to be able
       to join a given effort without being affiliated to something (else)
    4/ developping code publicly is a requirement for 3/ and I think and
       overall requirement of the GNOME project.
    5/ changes in direction need to be made public. Otherwise points 1/ and 2/
       are useless, we plan A initially and the fact that B got implemented
       instead is not public knowledge (a CVS commit is not public knowledge)
       and we get surprises and flamewars at the end. The change may be just
       the Right Thing to do, but that probably mean something changed since
       1/ and 2/ (or a new genius joined the project)
    6/ is needed to verify that the overall result fits the needs of the
       whole project (example if libxml2 took 10 seconds to parse a file
       I assume people would object to using it even if it fits the initial
       specification, similar if the code is too buggy).

 My initial take is that announcements should go to the foundation-list and
gnome-hackers. Debates (if there is any) should go to gnome-hackers (or a
separate list for the project if there is any, at least people are warned
taht there is such a discussion).
 If you refuse the gnome-hacker list to be the Committee evaluating how
thing should go, taht means that you don't want input from the project as
a whole. In this case this is not part of the Gnome project and one should
not expect to see it ending up on the Gnome platform.

 It is sure this won't allow people to build expectation (like for soup)
that a piece of the infrastructure can be developped closedly and dumped
"once done". I do think this is a good thing. If you disagree please state
in the steps 1/ to 6/ what you don't want to be put as a rule, and if possible
why.

 Of course for project not intended to end up in the Gnome platform like
application on top of it I don't suggest to follow this, though requiring
3/ 4/ and 6/ for being part of a Gnome release sounds a bare minimum.

  For the record the IETF has been following such a process for more than
a decenny, W3C work similary at least withing the member group, seems Python
works the same too. We need to grew up, the absence of a process is one of the
reasons why the project maintainer are left alone to criticisms, why conspiracy
theories builds, and why back channel communication has grew up so much. All
3 aspects are a poison for the project, and I expect this to reduce them.

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Sep 17-18 2001 Brussels Red Hat TechWorld http://www.redhat-techworld.com