specification process

Jeremy jeremy at
Sun Jul 12 08:24:37 PDT 2009

On Jul 12, 2009, at 8:56 AM, Jannis Pohlmann <jannis at> wrote:

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

That's what I immagined when the repo idea first came up. This seems  
to get rid of bottlenecks.


>  - Jannis
> _______________________________________________
> xdg mailing list
> xdg at

More information about the xdg mailing list