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

[Dietmar Maurer <dietmar ximian com>]

Hi everyone,

I would like to make alternative suggestion:

1.) Don't use things like "Fuck you" in mails going to these list.

2.) Don't allege that someone has dishonest motives, even if he get paid by a
company.

3.) Only flame other people if you know what you are talking about.

Obviously there was some communication failure between me and Havoc. Anyway, I
think we have solved that issue, and it was no big deal at all. It is a simple
decision:

    a.) use the PropertyBag interface to access configuration data
    or b.) use the gconf API directly.

We thought that it is reasonable to use the PropertyBag interface, and thus made
that small change, which is mainly a s/x/y.

I thing all those people who managed to annoy Martin should rethink there
strategy. Maybe I should add another point to the rules:

4.) Always consider that many people don't know each other, and communication
true email is a difficult thing. Be careful on what you say, in order to guard
against misunderstandings.

- Dietmar


Daniel Veillard wrote:

> [ 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