specification process

Jannis Pohlmann jannis at
Sun Jul 12 07:56:51 PDT 2009

On Fri, 10 Jul 2009 11:31:27 +0200
Olivier Goffart <ogoffart at> wrote:

> Le Friday 10 July 2009, Jannis Pohlmann a écrit :
> > Does it really matter who the contact points are? As Aaron said, if
> > two persons from the same project disagree, then there's something
> > wrong. So I think it's better to get people involved who are
> > actually working with the specs, even if that may be different
> > persons from time to time. In the end you can always ask someone
> > "is that the final and official word from your project?" to be sure
> > he gives the fact that he's acting as a representative some
> > thought ;)
> In my opinion it does not matter who it is.  but it has to be someone
> the project trust. And the decision of the desktop has to be taken
> after having consulted all the relevent person for the specification
> within the desktop. And we need someone that know who works on what,
> and will take care of broadcasting the announce of the spec to the
> right people.
> Also, I don't see what's 'wrong' when two poeple from the same
> project disagree.  That happens very often. KDE and Gnome are big
> project with lots of people with different opinions.  It is true that
> it is probably much easier to get consensus within a single desktop
> than between desktop, but still, conflicts happens.

How about this:

We establish one or two persons per project as general
contacts. Whether they are part of the release team or not is
irrelevant. These are the persons to contact when a new spec or
whatever is brought up. They are also the persons to contact when
per-specification contacts (see below) are unresponsive.

Together with the meta data which holds information on the adoption of
a spec in various projects, we list one or two persons per project.
These are the per-specification contacts which are ideally involved in
discussions and can be contacted e.g. for adoption status updates
before a new version of a spec is released or when someone feels that a
spec needs to be changed/improved. Ideally, most of the communication
happens on public mailinglists and via the xdg-specs repository, so
whenever a new projects wants to be listed in the meta data of a spec,
one of its developers can extend the meta data with their own project
information and request one of the admins to merge this change.

What do people think?

  - Jannis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : 

More information about the xdg mailing list