Notification spec issue: Ability to assign an icon *and* an image to a notification

[Aaron J. Seigo]

On Friday 26 June 2009, Jannis Pohlmann wrote:
>   - there's an always growing interest in new cross-desktop specs and
>     shared D-Bus services

+1

>   - there are different opinions on how specification X or Y should be
>     maintained. Unresolved disagreement leads to dissatisfaction for
>     all parties involved. In the end there's danger of specs being
>     ignored by potential users or abandoned by their maintainers.

+1

>   - there's absolutely no pre-defined standard way to make a spec
>     "freedesktop.org". 

yes, that is one of the main issues (another separate-but-related one being 
handling of the fd.o owned deve infrastructure)

>     People talk about "hijacking the namespace" but
>     in fact most specs seem to be introduced without a proper
>     discussion to see if there's a consensus on their design.

"introduced without a proper discussion" and "hijacking the namespace" are 
semantically equivalent. it's been a bit of a struggle to get people to 
understand why this is a problem, at least until i put it into such black and 
white terms.

>     (Just take the thumbnailer D-Bus spec as an example. Nokia likes it
>     and so do I. There's a spec, there are two reference
>     implementations (hildon-thumbnail for Nokia, tumbler for
>     Thunar and Xfce) and the D-Bus API uses the org.freedesktop
>     namespace ... but is it really freedesktop? Alexander Larsson for
>     instance doesn't think it's a good choice for Nautilus. So, who
>     is going to decide about the spec integration on freedesktop.org?)

have you read my vote-with-your-feet proposal where we store this information 
in a shared git repository, making it:

* self evident which are agreed upon standards (or at least be able to measure 
the criterion for that pragmatically)

* easy for third parties developing software for our platform(s) to know what 
they can rely on where.

in your case, if i'm writing a maemo specific application, i don't really care 
what nautilus, konqueror, dolphin or thunar use, do i?

if i'm writing an application that i want to run on KDE, GNOME and XFCE well, 
then perhaps i do.

as an upstream developer, i want to know that hildon and Thunar use it. that 
says this might be of interest to me, and i should look at how it interacts 
with our own (KDE's) thumbnailing system (which, iirc, is actually based on 
the last fd.o spec for this i saw? hmm... )

i think we can skip past the "who decides" and go straight to "let's record 
and then measure consensus". bottom up, not top-down.

>   - nobody being active on this list actually seems to know or belong to
>     the group of people (I know, this is probably not true) who are
>     responsible for administration and decision-making on
>     freedesktop.org and who could improve the situation if they wanted
>     to.

i disagree. yes, the admins are AWOL atm. BUT ... each one of us as 
participants share the load for decision making. there is no spoon. there is 
only us.

we CAN and, imho, MUST improve the situation. we can do this by making 
decisions amongst ourselves because we are the ones who are affected, we are 
the stakeholders.

the admins should be enablers and volunteers to the cause. they are not, or at 
least should not, be the bearers of the cause itself. that role is up to you, 
me and everyone else who is working together from the various projects.

somewhere along the line that got lost and people now wait on an 
administrative body that was never properly blessed with such a role and who 
have proven themselves unable to fulfill it: and not through malice or intent, 
but simply by being too busy with other things and it not being rational to 
expect a couple of people to keep up with ever expanding scope of this arena.

we need to take more personal responsibility as a group and start acting like 
we're working a meritocracy rather than a dictatorship.

> Neither does telling people they screwed up, Aaron.

honestly, Jannis, i tried the peaceful, happy and collaborative approach. 
repeatedly and over time. 

unfortunately, very few stepped up even once in those moments. i explained in 
detail, on this list, these exact issues, cause/effect, solution ... i even 
put time and effort into a working example of what i proposed, because i don't 
believe in just talking. however, the status quo remained and people sat on 
the sidelines.

fair enough.

so i took up the unhappy task of forcing the issue in a way that was not 
easily ignorable. it is not my preferred mode of operating, but i'm not 
willing to stand by and allow fd.o to slide ever further into the ditch.


my suggested take away from this would be: 

"if we don't like seeing people, many of whom are our friends and all of whom 
are are on the F/OSS team, screw up, and we don't like those same people being 
told they are screwing up, we need to get involved in a positive and proactive 
way and we need to actively support people trying to do positive and proactive 
things to avoid it coming to that."

does that make sense, Jannis? (honest question, not rhetorical :)

> Don't blame individuals for the lack of well-defined processes. 

you haven't noticed the number of times i've said that in this thread? :)

> freedesktop.org *is* the right place for all this.

mm. i think it can be. but right now it isn't. we can change that. it will 
take effort.

> Cross-desktop
> specifications, services and common APIs really belong here! I think

+1

> we all want this. What we're facing here IMHO is a governance problem,

agreed. now how many of us are able and willing to be part of the solution?

-- 
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 Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090626/515083ce/attachment-0001.pgp