Summary of the fdo disussion at GCDS

[Cornelius Schumacher]

Some notes from me as I attended the discussion at GCDS.

The basic idea, which was brought up by Robert McQueen, is to create a 
light-weight process to accept specifications as standard cross-desktop specs 
approved by freedesktop.org. The process would be that a spec is accepted as 
freedesktop.org spec, if the release teams of both GNOME and KDE accept the 
spec.

One basic requirement of this process is that the people involved 
constructively work together, be rational, and also consider the needs of 
smaller desktop projects. But as GNOME and KDE together constitute a pretty 
broad majority of the desktops, and a spec not supported by one of those two, 
would miss an essential share of support, this seems to be the most easy 
solution to define the criteria of acceptance as freedesktop.org standard. 
Obviously other projects also have to be involved and their needs and input 
have to be considered.

Some comments to the questions Aaron brought up inlined below.

On Wednesday 08 July 2009 23:01:54 Aaron J. Seigo wrote:
> On Wednesday 08 July 2009, Olivier Goffart wrote:
> > We agreed that freedesktop would have a wiki page listing the
> > specification/implementations and saying whether they are blessed by each
> > desktop, and the implementation status.
>
> and the specifications themselves go where?

In the end it doesn't matter too much where they are. freedesktop.org would be 
the place where there is a list clearly stating which specifications are 
accepted as a freedesktop spec.

> and i assume that software implementations must be accepted first before
> being eligible for fd.o hosting? (though i personally think fd.o hosting of
> software isn't really necessary these days in most cases)

The idea was that fd.o would only host accepted implementations, in case 
hosting is not solved in another way already.

> > In order to get blessed, it has to be accepted by the 'release manager'
> > of the desktop.
>
> so we're back to gatekeepers instead of letting the people in each project
> who are directly involved with those projects figure it out? i don't see
> the need to say how a project represents itself. if a project wants to have
> one fd.o rep, so be it. if a project wishes to have one group of people
> oversee the PIM related stuff and another group oversee the desktop shell
> stuff, etc.. so be it.
>
> having established contact points is good, but defining the agents who will
> officially accept proposals too tightly will lead to overworked bottlenecks
> in the process. we will, in short, likely end up repeating our current
> situation.

As said before the release teams of GNOME and KDE would be the defined points 
of contact, which take the decision about acceptance. This of course would in 
most cases mean to delegate the decision to the people involved in the specs 
under question, but as the release teams already act in a similar role for 
the individual communities, it seemed logical to extend that to the common 
activities in freedesktop.org. Bottlenecks are a concern, but in this case 
there seems to be a good chance that the existing structures prevent that to 
happen.

> there's also the issue of rejection. a project should be able to officially
> reject a specification. this is useful information for 3rd parties and is
> quite different than silence on the matter. if two projects are using it
> (say, KDE and XFCE, for whatever reason) and GNOME says "we reject that
> specification" that will likely matter to people considering implementing
> that spec. if GNOME was silent in that case, it might just mean they
> haven't looked at it yet. being able to register "we've looked, we don't
> want this" should be part of the plan.

Yes, a spec rejected by one of the communities would be marked and documented 
as such. Same goes for other aspects of the status of the spec, where we need 
to document, e.g. if it's proposed, or implemented, or deprecated, etc.

> > When someone want to start a project or specification, the suggested
> > process would be:
>
> so the proposal is that we do a bunch of asynchronous emailing about and
> try and document the emails after the fact.

The details of how to organize this best should be sorted out by the two 
release teams. Maybe a new dedicated mailing list would be a solution, 
tracking requests in Bugzilla, or some other implementation. Whatever is most 
practical.

> so again, i ask: what is wrong with putting all of this in a shared
> repository where one can do a simple "git pull" and get all the changes
> regardless of:
>
> * who you are
> * when you do it
>
> and when you put your blessing upon something, if it was in a repository
> then the documentation of that blessing would be simultaneous with the
> communication. in fact, it would be the same act.

There is nothing wrong with that. It might be the right implementation of the 
idea. That's something we still have to sort out.

> so that we have things scattered everywhere? for software projects, sure.
> but not having a central place for the specs only makes it harder on
> everyone.
>
> it makes it harder for 3rd parties find them
>
> it makes it harder for people who are otherwise involved with fd.o to work
> in a given spec as they now have to go out and find where it is, with no
> guarantee that it's even published in a way that allows community
> participation
>
> it makes it easier to miss a spec, or for multiple versions of the spec to
> start cropping up.

We would have a central place on freedesktop.org, which would clearly show 
which specifications are accepted, and where they are. The fd.o admins would 
do the administrative work of hosting this list, and the release teams would 
decide about what is listed there and in which state.

> btw, did any of you read what i wrote about the motivations and processes
> of the repository based model? was it shared as an option in the
> discussions at GCDS? if so, what were the objections or reasons for not
> wanting to address all the issues raised in what i wrote?

We didn't explicitly discuss this model. I think it could be seen as an 
implementation of the process we discussed. This is something which has to be 
sorted out over the next time. But I don't think it's in conflict with the 
basic idea of the process which was proposed.

> p.s. as an aside, the word "blessing" is a loaded term that implies certain
> emotional and even political aspects that shouldn't exist in the process.
> "accept", "reject", "abstain", "implement" are much more value-neutral
> words.

Agreed.

-- 
Cornelius Schumacher <schumacher at kde.org>