We need a process [Was: GConf vs. bonobo-config]

[Daniel Veillard <veillard redhat com>]

[ Cc' stripped and moved to hackers and board, if this thread develop it
  should finish on foundation-list gnome org lets keep it to gnome-hackers
  for the moment ]

On Sat, Jun 16, 2001 at 11:17:01AM -0700, Sri Ramkrishna wrote:
> This is not the first time this has been happening.  We've been having
> flamefests over this kind of thing before.  The foundation needs to pick
> this up and figure out how to deal with this.  It's a social/management
> issue not a technical issue.

   I think some of the reasons were exposed already:

"We also had an  extensive discussion on the gconf list (half a year ago).
Most people at Ximian are aware of the project, and I have even talked to
peoples at Sun ;-)"

  i.e. not recently discutted publicly, and use of private communication
channels, don't look further.

> How do we avoid these kind of things in the future.  Thats the discussion
> I would like to see.  Otherwise we're going to be seeing this again in
> another couple of months.

  Well it's notorious that some people don't want to make technical
discussion on the public lists anymore. Unfortunately the Foundation
can't force people to communicate in public instead of back channels.
But we should be able to build a process which makes back channel useless.

  My personal opinion is that this kind of policies are only applicable
within the scope where those channels are created (companies, service
contracts, etc...). It's very hard to break the rule of locality (you
have a 1000x better bandwidth with the guy in the next cubicle than
with someone in another company and possibly on a completely different
timezone). In its last days Eazel decided to ban all their private
mailing lists, I would not be that extreme but I think it does matter
to avoid segmenting the communication (not only per companies, but also
per topic, c.f. the fact that not everybody were aware that changes were
upcoming), and keeping at least the feedback at the global level minimum.

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.

I remember discussing with Michael who argued that this kind of burocracy was
slowing things down and should be avoided like the plague. Unfortunately
this is only by going through this kind of processes that we will avoid
clashes at the last moment between project and build a *concerted* roadmap
for the overall project, avoid wasting effort in duplicated code, stupid
flammage, and misuse of the geniuse of our developper team.

I also know that people are gonna object stating that they have private
interest that can't be developped using such a process. My opinion on this
is then it is a proprietary project and has nothing to do with Gnome. There
is few harsher marketpace than the web industry, yet the W3C managed to grew
a membership of more than 400 companies agreeing to follow similar rules.
The goal is that ending up with a common shared set of spec (code in our case)
and developping them in concert is still more beneficial than the slight
advantage one could gain from a version where the IP, roadmap (or code in
our case) is kept by the individual companies.

> It's very disheartening to see this kind of flammage on public mailing
> list between people.  I hope GNOME can figure out a way out of this.  It
> won't be for technical reasons that GNOME goes down the toilet.  It'll be
> for things like this.

  yes I'm afraid that if we don't grew up we will go down the toilet faster
than we can imagine now. A bad technical decision can be remedied. A bad
process for taking decision makes people leave, and that is not fixable,
we are all unique.

  Now I would like Martin and Sanders to exhibit the requirement and
roadmap for Gnome-2.0 again, check that there is not objection, if there is
then we need to renegociate globally the requirement and roadmap. I also
think taht the projects leaders are respnsible for the roadmap and the
fact that the due amount of communication is done. Failing it expose the
project in question to be renegocied globally, possibly cancelled for
the use of an alternative project. But if the project is not breaking the
rule then it is in its own right to finish.

  We unfortunately need such a process, it is clear that we cannot rely
on tacit acceptance of a set of unguided project to build a future to Gnome
both the project and the programmers team. I don't know if this will be
accepted (we don't have that many rules and they tend to be ignored anyway)
but at least as a Fundation Board member I think we need to try to build
this process and make sure it's accepted.

  yours,

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

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers