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
bjt23 at cornell.edu
Thu Jun 25 14:38:19 PDT 2009
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? 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.
More information about the xdg