specification process

Aurélien Gâteau aurelien.gateau at
Fri Jul 10 06:12:37 PDT 2009

Cornelius Schumacher wrote:
> Following up on the discussion about at GCDS and the 
> additional input on the mailing list, I wrote down a specification for the 
> process how to manage specifications. It's based on the 
> consensus we built at GCDS plus the input which came from Aaron and others 
> before and after the meetings.
> To bootstrap the process I wrote it down as a specification 
> following the proposed process. You can find the text at 
> Please have a look and comment.

# About "### Overall Acceptance States"

I am wondering if there should not be a way to represent specifications
which may have been declined by one "major" desktop but implemented by
the other one and by "minor" desktops.

(sorry for the major, minor words, I can't find better terms)

# About "## Project Hosting"

There is no lack of hosting solutions these days, so I think
newly-approved projects should only be hosted there if they are
implementing an fd.o spec. This should help reducing confusion.

# About "## Appendix A: Specification Meta Data Format"

Sometimes implementations are at application level rather than
desktop/organization level (for example the thumbnail spec). So I
suggest replacing the <organization> element with the more generic

I think we should encourage implementations to list themselves as
adopters. This helps to have a birds-eye view of the ubiquity of an

The <adopter> element should include contact information for the
implementer so that it's easier to gather interested people when there
is a need to make the specification evolve.

The "specversion" attribute of the <version> element should be mandatory.


More information about the xdg mailing list