improving fd.o transparency and spec process documentation (was Re: Notification spec issue: Ability to assign an icon *and* an image to a notification)

[Brian J. Tarricone]

On 06/25/2009 01:49 PM, Brian J. Tarricone wrote:

> But I don't really know how to fix that. You mentioned elsewhere about
> being able to track and record consensus -- I think that's important.
> What tools exist to do that? Is it necessary that it be a very formal
> process, or is a simple series of "My name is Foo and I represent Bar
> and I approve of this spec" in a list somewhere sufficient[1]? Then
> potential spec users can say "I can implement this spec, and it should
> work with apps on any desktop," or at the very least can easily
> acknowledge, "well, I can implement this spec, but there may be interop
> problems on desktop XYZ," and at least make an informed decision.

Looking at fd.o/Specifications again... it's organised pretty sub-optimally.

There are three sections: stuff that has de-facto adoption, stuff that 
doesn't, and stuff in the requirements-gathering stage (well, and a 
fourth about proposed X extensions [three of which seem a bit farther 
along than "proposed" now], but I'm not sure why that's distinct).

The question is how do you judge when a spec can be moved into the first 
"has de-facto adoption" category.

I like that a few of them in the list (DnD spec, X clipboard 
explanation) say "shared between GTK+ and Qt" or similar.  Making this 
more formal (as in, a required element of the spec) would make things 
much clearer.  For toolkit level stuff, a list of the toolkits that 
support it.  For desktop level stuff, a list of the desktops that have 
an implementation of the spec, with links to those implementations.  I 
guess that's the more important thing -- not that J Random Hacker claims 
to represent some meaningful portion of a particular desktop's 
stakeholders, but that there's a real implementation working on that 
desktop that people actually use.

Then of course you have to question whether people actually use it.  I 
could claim to have written an implementation of the spec for the XYZ 
desktop, but if I'm not involved in the desktop beyond that, and no one 
has written apps for that desktop to use my implementation of the spec, 
and/or users of that desktop don't actually install my implementation, 
then that's useless.  Not sure how to enforce that -- maybe just social 
pressure, and vigilance on the part of other fd.o participants to remove 
links like that from the wiki when they pop up (but then you can get 
into a wiki-edit war if someone really cares that much... hopefully that 
wouldn't happen, but I'll just throw that out there).

There's also the problem of actually making this happen.  Obviously I 
happen to think that having this list of implementations would be a good 
idea.  Let's say a bunch of other people also agree.  Who's going to do 
the work to convert that specifications page to the new format?  I'd be 
interested in helping out if someone else were to get the ball rolling, 
but I can't say that I have the time (and, I'll be frank: the 
inclination) to lead such an effort.

Another idea: people aren't allowed to use the org.freedesktop namespace 
for anything if their spec isn't hosted on fd.o.  It seems that fd.o has 
some procedural problems regarding creating new accounts and granting 
access to people who need it, so I suppose that would have to be fixed 
(I have no idea how) before something like this could be practical.

Anyway, that's all for now... I have some other things I need to get 
done this afternoon.

	-brian