Re: GNOME Enhancement Procedure

[Tim Janik <timj gtk org>]

On 18 Jun 2001, Owen Taylor wrote:

> Joe Shaw <joe ximian com> writes:
> 
> > > More as they come to me. :)
> > 
> > The only thing that concerns me about the whole process is how things
> > that do not fall completely within the GNOME project will work with it.
> > GConf and GTK+ are examples that I can think of offhand.
> > 
> > Using GTK+ as an example, if the GObject or ATK stuff were being done
> > after this were in place, would they have to submit to this process as
> > well as the normal GTK+ process? (Which is usually a proposal to the
> > list, some discussion, and approval from Havoc, Owen and/or Tim)
> 
> Since the process is essentially independent of GNOME, except
> for the specification of the board as the adjucator of last resort
> for some issues, I see no problem using it for loosely
> affiliated or even unaffiliated projects.
> 
> Most likely in case of failure of the process, Tim and I would try to
> mediate (pistols at 30 paces if we can't agree) rather than turn to
> the board, but mostly the procedure is based on who is interested in
> an issue, not on some fixed set of GNOME people.

i have to add here, especially with me being very busy over the last couple
months, that some decisions are on occasions being made on a "who writes the
code gets to rule" basis.

i recall, back in the early days of owen and me taking over maintainership of
gtk, there's been an issue that owen and me could quite agree upon (whether
that was some relgious coding style issue or some
tim-we-need-omipresent-flexibility vs. owen-keep-it-extremely-simple-stupid
issue, i can't quite remeber ;). after some lengthy personal discussion, i
was on the edge of nagging peter mathis to finally reach some "blessed,
dictated consensus", when owen mentioned something along the lines of
"in the perl community, we used to follow `who writes the code gets to rule'",
and that's what basically resolved the issue in the end and got stuck
for many future issues to be resolved.

that might sound pretty harsh at first, but really, it's what kept the
development alive over issues where consensus wasn't immediately reached
upon (e.g. the 1.2 GLib main loop, GtkBindingSet, container resizing,
2.0 focus handling and whatnot).
trying to serialize and summarize the steps that usually lead to
our resulting API over issues with conflicting perceptuations:
A:    conceptual idea is raised (public or private doesn't really matter,
      this is usually carried into the public soon enough)
B:    a different conceptual approach is presented
A&B:  attempts are being made to understand the opposite side, that's often
      been the most important part, since here, misunderstanding are being
      resolved and both sides ususally gain a broader picture of what's
      required (and always, ther're a lot of misunderstanding to be resolved,
      both communication wise and technically, even for coders that work
      together as long as owen and me)
A(B): an API/implementation is presented
B(A): API/implementation is taken apart and refined to meet both side's
      requirements

we usually ended up with something that is a mixture of overly-flexible
and extremely-simple and normally also meets the requirements of 90% of
the public (users).

while the basic steps probably won't appear astonishingly genuine to most
hackers, there are a few important points that have to be adheared to to
make the process viable as a whole:
- don't compose messages in a way that may be perceive as a personal
  attack. instead concentrate on technical reasons and make an attempt
  to cover issues in detail that might be mis-preceived
- ignore parts of incomming messages that could/are intended to
  be perceived as a personal attack, while still accumulating technical
  facts presented
- make a fair attempt at understanding the opposite sides and situations
  presented. without understanding motivations other than your own, you'll
  _never_ reach a conclusion that the majority of users can benefit from,
  and in the end, that's what really counts
- be prepared to take a few days off on the issue at hand to:
  1) let emotions calm down (if you really have to, only write flamage mails
     after your pending sleep cycle has been completed)
  2) reflect on the different requirements presented
  3) reflect your own ideas after shifting onto the opposite side of
     the argument

in practice, most people are probably aware of the above points, but don't
pay them the attention the deserve. the results are huge flame baits that
serve nothing but a good laught in retrospect and, sadly, lessen the chance
of fruitfull future discussions.

> I certainly think a RFP process would have helped with both
> GObject and ATK in terms of clarifying the rational and
> requirements, and making sure the overall designs fit them.

i'm not sure i 100% agree here.
the RFP is an attempt at formalizing comunication, which tends to reduce
flammage by some amount, but also has a tendency to increase latency
and can't really stop people from fighting each other if that's the
main issue they persue.
for GObject (or libgruntime ;) specifically, there's been quite some
evolution of that going on since you first prompted me for inclusion
of the BseObject system into GLib, i don't quite see that fit the RFP
process.

> As long as the maintainers of a project are involved in the process
> I think the possibility of errant proposals being approved
> is minimal.
> 
> And if Tim and I are completely ignoring what everybody in GNOME
> wants, then probably you probably should create the Gnome
> Toolkit or switch to FLTK ;-)
> 
> Regards,
>                                         Owen
> 
> [ Just my opinion - haven't discussed this with Tim, so perhaps
>   the pistols will be needed sooner rather than later ... ;-) ]

<bang> ;)

---
ciaoTJ