Proposing the StatusNotifier specification

[Aaron J. Seigo]

On January 13, 2010, you wrote:
> On Tue, 2010-01-12 at 10:13 -0800, Aaron J. Seigo wrote:
> > On January 12, 2010, Aurélien Gâteau wrote:
> > > I remember one of the outcomes of the freedesktop.org discussion we had
> > > at Gran Canaria Desktop Summit was that a spec didn't have to be fully
> > > finalized to be allowed to use the org.freedesktop DBus namespace.
> > 
> > personally, i think it needs to have at least significant "sign on" by
> > xdg projects. these kinds of conversations that are tentative, unsure
> > and spiral towards inconclusive results are precisely why i have
> > advocated the use of a metadata file in the repository.
> 
> I agree with you 100% (may be even 110%) on the need for a file, and a
> process for how that file gets signed.  I don't think that we have
> enough process for that today.  I think that we need one, which
> basically amounts to bylaws of FD.o on specs.

Yep, and I've submitted such a proposal a few times to this list. There's a 
git repo that goes along with it that has a README containing the proposal as 
well: http://gitorious.org/xdg-specs/

It's probably not perfect, and I'd love more feedback. Feedback that has 
already been received has been merged into the proposal, and it has improved 
due to that feedback. :)
 
> I think there are some unanswered questions:
> 
>       * Who can sign it?  I think there should be some way for projects
>         to designate who from their projects are the go-to people when
>         looking for such signatures.  In general, you could say the
>         boards, but that's unlikely to be the right folks.  I'm guessing
>         technical standards aren't their expertise.

I think that's up to the projects involved. I know within KDE that we can 
quite easily ensure that appropriate people (in the plural, it will be 
different people depending on the topic) are involved and if they implement it 
in KDE and get the support needed to do so from their fellow developers, 
that's enough for KDE. This is really just basic project mechanics, and I'm 
certain that GNOME is similarly mature enough as a project to do the same.

I don't think that there needs to be a formal registry anywhere, but people 
who sign on, if they aren't known to others involved (and so their credibility 
is assured as well), they should be able to provide support for their approval 
of the spec (e.g. links to the project's relevant mailing list discussions or 
links to the code already in their project's source code repository that will 
be or already is part of an official release).

We could agonize over this issue and create a bureaucracy, but I believe we 
can manage without one. If we do end up needing one (due to abuse) we can set 
one up later as needed.

Does that sound sensible, or do you think I am being too optimistic? ;)
 
>       * What votes are needed?  Is an XFCE vote equivalent to a KDE
>         vote?  Do people classically categorized as "desktop
>         customizers" (Maemo, Moblin, etc.) get their own votes or are
>         they lumped in with GNOME in this case?

That's probably the biggest open question, and discussion was started but 
never concluded (due to lack of involvement, actually). My thoughts are this:

Given that fd.o was started by KDE and GNOME and was an organization for those 
two projects for all practical intents at the start, we could begin simple and 
say "It needs the sign on off both KDE and GNOME to be recognized as 
accepted."

I don't think that's a useful long-term strategy, however, it's just something 
that would allow us to start going.

There are other actors at the table here, and their interests should matter in 
a concrete sense. That's the only way we can effectively grow this 
organization, while showing projects the respect they deserve.  So what might 
work?

I don't think, simply based on relevancy metrics, that having XFCE or LXDE 
sign on would be the same as having KDE or GNOME sign on. Ditto for Maemo or 
Moblin. As these projects grow in importance and entrench themselves as 
meaningful players in this space, they could certainly be "promoted" upwards.

This means having a multi-tier (or even "just" two-tier) system where (at 
least for now) we would look for "two out of three support" where KDE and 
GNOME are both "one" and the other projects must come to consensus and "vote" 
as a block. I would hope over time that this would grow and we'd have other 
projects. join KDE and GNOME with a singular vote. How would that be decided? 
Consensus.

We are not an industry group grappling for a choke hold on each other's 
throats. I don't believe we need a bunch of rules and protections from each 
other. When/if another project achieves a similar significance in this 
particular arena (fd.o and the F/OSS client side space), I have no doubt that 
KDE and GNOME would recognize that. It is in all of our best interests to work 
together and ensure there is useful representation, and to ensure that happens 
we need people around such as you and me to remind each of that as needed.

Executive summary time:

* KDE and GNOME each get one "vote", which is recorded as their approval in 
the metadata file

* The other projects who work with fd.o would form a block representing a 
third vote, and they'd have to work out consensus between themselves. 
Individual projects would record their individual approval  in the metadata 
file so that consensus would be very evident as well.

Note that in the system I proposed, projects can also register than they 
reject a given proposal. I've swayed between the idea of having a veto or not, 
and I don't think it would be useful to do so, at least at the start, given 
the complications it could create and given that it would be an edge case.

> I think that FD.o was started as a place for discussion, and we're
> finding that we need a little bit more than just a place for discussion.

Agreed.

> Different people seem to apply different weights to discussions here and
> the specs -- and we should be clearer about what they mean (both the
> discussions and the specs).

We also need to be clearer to those watching from the outside. Even when we 
all agree internally, often that looks like complete chaos and uncertainty to 
the outside. :)

> More on topic, I'm worried about having to ship code that implements
> StatusNotifier under "org.kde" and "org.ayatana" real-soon-now.  And
> since we don't have answers to these questions, or a process, I'd hate
> to see this spec held back by something that doesn't exist.

I don't think the process that was proposed is heavy-weight, difficult or 
tricky.

So I'm going to make a brash suggestion: instead of waiting and allowing this 
to be held up by those who do not have an opinion. do not wish to share, do 
not have the time / energy to get involved, etc .. let's simply go ahead and 
do this thing. 

Marco has the spec draft in a branch of the git repo; one of us with commit 
rights to the git repo simply needs to merge that branch with the mainline

KDE can quite easily sign off on the spec in the metadata file, we already are 
shipping an implementation.

If GNOME (or a consensus of the other projects) can sign off on it as well 
then we're "done" and can move on.

If anyone has a problem with this, they need to speak up. In fact, if you 
think this makes sense, then I (or you can, if you wish :) will draft a "speak 
now or forever hold your peace" email to this list proposing that we adopt 
such a strategy and if there is no significant negatives, we simply "let the 
people doing the work decide" and put this in place and fd.o will evolve.

(As for commit rights to the repo itself, anyone with formal ties to one of 
the projects should be able to commit to it IMHO.)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks