• 1

Cituation request.

Do you have a citation for the submitted patches "story." Can you point to the specific patches in question in the GNOME bugzilla?


Re: Cituation request.

Hi Jef,

No, unfortunately I don't (which is why I flagged it up as needing a citation). Feel free to take it with a pinch of salt; I don't see any reason why the person who related it to me would have made something like that up, but without being able to look directly at the situation it's impossible to conclude anything.

Re: Cituation request.

You need to understand, that by repeating that accusation you raise tensions higher. That is an unattributed accusation cast widely across the entire GNOME development space. You have to understand that what you just did reinforces the prejudices on both sides. People who already mistrust Canonical will see that accusation as untruth that you were duped into repeating. People who already mistrust GNOME will read that to reinforce their own pre-existing judgements. By repeating that accusation you have most likely inflamed emotions on both sides and made it _harder_ for people to work together by introducing more contextual baggage.

If such a situation actually occurred it needs to be called out as bad behaviour on a case by case basis. I've seen zero public discussion about any specific handling of a set of patches that would be considered punitive bias. And I've looked. I've looked very very hard every single time such an accusation has been made.

And more over I can point to the work on the CSD feature addition to gtk which was spearheaded by a Canonical employee where things went smoothly and well. CSD was incorporated into gtk without any controversy because the lead developer worked closely in consultation with the rest of the gtk developers and got feedback early and made technical adjustments to the implementation based on that overall technical discussion. It wasn't a code dump from a closed-door in-house process. It wasn't a take it or leave it approach to feature development. It was _real_ collaboration. It was _real_ collaboration between a Canonical employee and employees of other vendors inside the scope of the neutral ground of the GNOME project. It happened quietly and respectfully. And it is a model of how its always suppose to happen.

If you want to lower frustration levels on all sides...find the _good_ examples and point out what went _right_. Rebroadcasting unattributed and unspecific accusations about bad behaviour does not help..it hurts..it hurts a lot.


Re: Cituation request.

"Raising tensions" is rather the point, I'm afraid (although I wouldn't have phrased it in that way myself). I want to see people address this issue, because there *is* an issue. My aim was to encourage discussion by pointing out that there could be failings in *both* communities which contribute to the current situation. Making sure that one "side" is aware of the others' point of view, of the *perceived* problems, is important I feel, whether there is any truth in the claimed existence of the problems or not. Because the perception is what people are acting on.

I know there are plenty of stories where collaboration is working properly. Over half of the GNOME documentation team is made up of Ubuntu people working directly upstream, and GNOME members work closely with the Ubuntu docs team. But that's not what people see, because no-one is interested in making a big fuss about it. People make a fuss about things like the Banshee referrals and Zeitgeist, and it's *these* issues that influence relations between the communities most, not the majority of cases where everything works as intended. The "minor differences between the two projects [that] are repeatedly being blown out of all proportion" need to be tackled, whether 99% of all other interactions run smoothly or not. And to tackle those issues you need to look at the FUD as much as the evidence.

Re: Cituation request.

I cannot stress how very very wrong I think you are in your choice of actions in how to move towards a resolution of this conflict. If the problem is fundamentally miscommunication, what you are doing is not helpful. Miscommunication can only be addressed with an an increase specificity...not general statements...not rumors...not stories. If you think there are specific cases where patches were punitively punished because they were brought forward by a Canonical employee..then be specific. Don't spread rumors. Be specific so the behaviour can be addressed.

You can't address "stories". You can't address "rumors." If you want to address specific bad behaviour or a culture of bad behaviour you have to bring up specific examples where you felt decisions were made for the wrong reasons. You've given the accused group absolutely nothing to work with as a basis for self examination of the processes they are using.


Re: Cituation request.

I think you're missing my point. What if you can't be more specific? What if you think you're a victim of bias but you can't provide concrete evidence? A lack of hard evidence isn't the same as there not being an issue.

For example, say I was a member of a minority group and go for a job interview. I don't get the job, but I was well-qualified for it. It's possible that I didn't get it because someone more suitable turned up. But it's also possible that I was discriminated against because I belong to a minority. A lack of evidence means that I can't prosecute the employer for discrimination (or accept that I wasn't the best candidate for the job), but it doesn't establish what the *actual* reason for me not getting the job was. And it doesn't change how I feel.

With my post I wanted to contrast the perceptions of the situation that both groups have, so that it's clear that there's more than one side to the story. This involves acknowledging (what could be) rumours, because they may be shaping the opinions of one of the groups. The other group needs to understand that.

Conflict can be addressed by building trust and encouraging forgiveness of past indiscretions (real or perceived). If you can get people to a point where they *always assume good will*, then rumours lose their credibility and small indiscretions fail to turn into big issues. Addressing issues on a case-by-case basis may not achieve this, especially when one party has insufficient evidence to definitively prove their point. They may instead feel that they failed to achieve justice on a technicality (whether they were right or not). This happens all the time - see, for example, the responses of various groups to the (multiple) UK governmental inquiries into the Iraq war. There will always be people who dispute whether justice was achieved.

Re: Cituation request.

In this case you _can_ be specific. You just decided not to hold yourself to the necessasry standard. When people tell you "stories" about patch submissions gone wrong...respectfully demand that they point to the patches in question and the public discussion archived in the gnome bugzilla around those patches.

Stop broadening out the discussion to hypotheticals which simply don't apply. This isn't a closed door job interview. GNOME patches are submitted into a process that is publicly archived. There _is_ a public record, you just have to have the guts to require the people who tell you "stories" to point to it.


Re: Cituation request.

I've asked the person who told me this story to point me to the bug report. They haven't gotten back to me yet, but I'll let you know if/when they do.

You still haven't acknowledged my point that this may be a wider sociological issue than something that can necessarily be tackled on a specific, case-by-case basis.

Re: Cituation request.

That is correct. I haven't acknowledged it because I don't think there is any merit to it for what we are talking about here... cultural bias against a single corporate entity inside what is already a multi-entity decision making process. The established process is open and transparent. Vague allegations have been made and those need to be supported with specificity or else no forward process can be made.

Compare and contrast how the geek feminist movement is directly challenging a culture of bias by calling out bad behaviour amongst males in the geek culture. They aren't telling vague stories...they aren't spreading rumors. They have decided to call out bad behaviour on a case by case basis and get it addressed. By pointing out specific cases the draw attention to the larger problem of cultural bias for the rest of us so we can begin to modify our own behaviour in subtle ways.

I am forthrightly and immensely skeptical at the very concept that it takes more courage for any particular Canonical employee to step up and make a direct allegation about the GNOME development culture than it takes one of the women in the larger ecosystem of the geek community to stand up and point out sexist exclusionary behaviour at conferences and in other places. If the long standing culture gender bias can be addressed with direct confrontation on a case-by-case basis.. then surely bias against the employees of a single for-profit corporate entity can muster up the courage to do similarly in the context of the GNOME project culture.

Feel free to look through the available guidance for corporate entities that exists to address institutionalized cultures of discrimination in a corporate setting. I am not suggesting anything out of step with guidance that I can find.


app indicator + zeitgeist

I have no influence, and contribute less than anyone in GNOME. But I do have a eye for bad taste. And about you point [3] App indicators are bad taste. And yes i'm only picking out a minor point, much of your article is very reasonable and points out the rocky path ahead :)

But... about [3].

Some of the design stuff in app indicators is worthy of GUI hall of shame. I mean, objects that fade when the equivalent of your mental attention (the pointer) hovers it. It's like turning to person starting a conversation, and then they disappear. It's so odd. Secondly the very well thought out keyboard activated on screen icons in gnome, has been replaced with app indicators. Before pressing volume/light controls was a onscreen transparent icon (huge) that was _centered_ on the screen. Now it's in the top right corner using about <5% of screenspace on some laptops. I've seen users miss 'app indicator' notify. When user presses a button themselves, there is no reason to hide it(!) in a corner, show that the intended action occurred - clearly.

I would have understood if all the work went into merging the window list and notifications. But no, instead we invent a third way to interact with applications. Great! It shows lack of understanding the mental concepts the existing desktop attempts to provide. It can't be a surprise that there has been resistance in gnome to add more features to the notification area. Read up on early gnome2.x

Zeitgeist is much more interesting. However, it's also very much research, both UI and tech because it has to run at all times, and not suck power and memory, and still gobble through huge amount of data. That's hard to get right.

Given the later architectural changes done in tracker to better support the goals of concepts of zeitgeist, _and_ that the only app using it at that time was an ill conceived 'journal', that in reality was more like a 'zeitgeist' debugger than an actual use case. It was the right thing to reject zeitgeist as a of the library foundation framework. It lacked user goals to accomplish and it showed.
I still think that finding the correct 'item' is hugely important, and tracker is big part of this.

Yes i'm harsh, but it seems that just because somebody spent valulable time on a project, it's by definition a valuable addition to gnome. Well, it isn't. We have to be able to say 'no'. If it's too hard to 'add' features after installing the desktop, fix that instead of breaking it for the majority by forcing stuff as default.

Re: app indicator + zeitgeist

The Indicators were mostly not accepted because Canonical refused to write a patch for GNOME Shell as well. Canonical only provided a GNOME 2.x patch.
Of course GNOME didn't accept a patch that developed a new technology for an aging DE when at the same time the technology wasn't even made compatible with Shell/3.x.

Re: app indicator + zeitgeist

With comments like "worthy of GUI hall of shame" it seems like you've made up your mind and you're not willing to listen to another person's perspective.

Personally I really like it that the Ubuntu notifications fade when I move my mouse over them. Sometimes I want to read whatever is underneath them. I don't want them taking my attention away from what I'm doing. For me, this was an excellent design decision.

Of course I don't know if you would ever take this perspective into account. Maybe you would, maybe not. Since you think it's literally shameful, I get the impression you'd not. But I'd be very happy to be wrong.

Re: app indicator + zeitgeist

I know it's harsh, and as you say, it is too harsh :). You are completely right.

Maybe it's because i'm actually disappointed :), I expected better?. It's such an obvious misunderstanding of wimp/mental models at work, humans try to fit a model to abstract behavior, and having the pointer just point at stuff to go away, is clearly backwards from everything else it does. Think of the pointer as an extension of our attention.

I'm not saying you do not want to see what's underneath, it should just be done in another way. But at worst, the notification disappears after like what... 15 secs?

Of course this is not research, i'm (almost) pulling it from my.. well you know :). Real testing (but it's quite hard to do such testing, almost impossible) would of course be the right way to do it.

That you can grasp it, i have no doubt. I'm sure most do after a few surprises. But now they have to reevaluate their existing model of what a the pointer can do, when exploring new interfaces or just using existing one. It might make stuff disappear or it might be a way to active way stuff pointing and clicking.

Re: app indicator + zeitgeist

You suggest that I "Think of the pointer as an extension of our attention." Maybe that's how you actually *experience* it (as compared to forming a theory about it). But I have never experienced it that way (with the possible exception of when I first learned the concept of the mouse). Instead, I pay no attention to the pointer unless I have to. Most of the time I have no idea where it is and I don't care. The only time I care is if it's in the way of what I'm paying attention to, or if I need to move it to perform some action.

In short, I think you've constructed a theory around an invalid assumption.

I was pretty heavily involved in the design of app indicators. As far as I know, there is nothing in them that fades, in any situation. And far from “add[ing] more features to the notification area”, they have replaced the notification area entirely with something that deliberately has fewer features. So, what are you talking about?

Re: What?

That would be pretty embarrassing if missed what project it was. But it would be stupid arguing against the design though. Isn't notification-osd part of app-indicator project?

At least up to 9.10 , when you move your pointer above a notification (in compiz) it fades away allowing you see what's underneath until it disappears after 15 secs.

You are correct that app-indicator does remove features, flexibility might be a better wording, my bad. The problem is that it also encourages applications to use it, which of course is the point, but the history of notification area was pretty specific about applications not belonging in the bar.

I know it is a poor argument, but the notification area was partly left as is because a good, well designed and easy to use API would only encourage more use from applications as one more way to active the same application. But something was needed to convey system events. That is the impression I got from the discussion back then.
And yes it's a very bad way to treat your developers ;).

The hope was that people would have time design the right thing. App indicator is of course a very good attempt at that, but it's also further down the path of having multiple possible actions to activate applications. That is my main objection.

But i'm arguing against somebody more qualified ;).

PS: I'm sorry about the grammar and spelling errors ;). Poor excuse, but english^H^H^H^Hrish is not my native language :).

Oh, sorry, I didn’t realize you were talking about Notify OSD. No, that has nothing at all to do with application indicators.

It’s an interesting point that having an easier-to-use API might make people use indicator status menus more than they would have used the notification area. But we can discourage overuse of indicators in other ways (interface guidelines, ridicule, and so on), whereas there was no other way we could have made the notification area more consistent.

I don’t know what you mean by “system events”, though. What kind of interface something should have depends on how much of your time it needs, how complex it is, whether it needs to interrupt you, and so on — not on whether it’s “system” or not.

Re: app indicator + zeitgeist

I don't see how you compare Zeitgeist and Tracker.
A metadata storage and a logger are not the same. And if any attempts to solve user stories of the other side then it is attempting to become a kitchen sink of data.
We learned our lesson and currently we are doing lots of zeitgeist work with upstream projects. Rhythmbox, Banshee, totem and gedit are shipping plugins and soft dependencies. Also we have some patches for GNOME shell that got reviewed ans hoping to get merged upstream for 3.2
Describing Zeitgeist as research is fair but then how is tracker not research. We have more community deployment and usage. Docky, Dockbar, Synapse, Tomboy, AWN, Cardapio. All these projects might not be upstream gnome but pretty well spread.

This suggestion that GNOME makes it difficult for Ubuntu to contribute has been doing the rounds, but the evidence that is offered has never convinced me. Let's break it down:

* Libappindicator: totally at odds with GNOME's direction, and the attempt to have it included in GNOME was half-hearted. It was developed in house with no GNOME consultation and then dropped from a great height.

* Zeitgeist: does this even qualify as a Ubuntu project? Even it if does, its lack of acceptance into GNOME isn't the big deal that some people make it out to be: it's quite common not to be accepted first time round, and we've repeatedly encouraged Zeitgeist to apply again and to work towards technical integration with GNOME modules.

* Refused patches: I'll wait to see if any evidence turns up. I'd be surprised though: GNOME is usually crying out for patches.

* Design schism: I've been involved in GNOME design for a while and I've never seen a serious attempt by Canonical designers to participate or to influence what we're doing. Maybe this great divergence happened before my time, but everyone I've asked about it is baffled by such statements. Are there any public records of attempts by Canonical designers to change GNOME's direction? (That's an honest question: I've never seen any.)

I'm not saying it's easy to contribute to GNOME. Collaboration is never easy: it takes time and effort. But the idea that GNOME offers particular resistance to Ubuntu seems groundless (feel free to prove me wrong though). We *want* more contributions, after all, and those contributions that do come from Ubuntu/Canonical are welcomed with open arms.


Zeitgeist is not and never was an Ubuntu project and Zeitgeist wasn't even completely rejected. The integration of Zeitgeist into GNOME Shell was postponed. THAT'S ALL, dear PhilBull. In fact Zeitgeist is already partially integrated into GNOME 3.0. For now it's only in Totem (the movie player). Better integration will follow in GNOME 3.2.

Phil, you better get your facts straight. For examples look at the sponsors list on http://mhr3.blogspot.com/2011/02/my-work-zeitgeist-hackfest-2011.html
You'll see the GNOME Foundation and 3 others but no Canonical.

It's not an Ubuntu project but it is "Ubuntu-y". For example, the development is done on Launchpad (and this was apparently one of the reasons given for rejecting it: not using GNOME infrastructure).

I think it's fair to say that the Zeitgeist developers identify closely with the Ubuntu project. See this (old-ish) post from Seif Lotfy: http://seilo.geekyogre.com/2010/06/my-take-on-zeitgeist-and-gaj-not-being-in-gnome-a-personal-rant/. Seif cited a potential reason for the rejection as "our high affiliation with Ubuntu and Canonical". Whether this is justified or not is a separate issue; Zeitgeist is associated with Ubuntu, which is what I was trying to claim. So I think I'm vindicated on that count.

Again, a lot of the baggage here is contextual and not attributable to bias. Even Seif has more recently apologized for statements he made that made the relationship difficult.

And more to the point. GNOME has a category for external dependencies. It was established as part of the conversation concerning the discussion of the GNOME Journal that zeitgiest would fit well as an external dependency once one of the GNOME modules relied on it. Using launchpad for an external dependency is not contentious. Just as using freedesktop.org infrastructure for an external dep is not contentious.

The only issue of merit in the zeitgiest discussion was how to appropriately expose zeitgiest functionality in the GNOME 3 interface...specifically Shell. Everything else was unfortunate theatrics with got in the way of that work. But we are past that now and people are collaborating on the design and technical issues in the scope of GNOME 3.


I'm not saying that GNOME as a whole makes it difficult for Ubuntu to contribute, just that there are people in the community who *are* biased against Ubuntu/Canonical who I think may have made it more difficult for Ubuntu people to contribute. These people do exist - I've met them! Whether they have acted against Ubuntu consciously, or even significantly, I don't know, but you must admit that it's a possibility.

I fully admit that the specific examples I gave are far from clear cut, and my accusations in these cases *could* be entirely groundless. But they could also be justified examples of situations where some degree of bias led to unfair treatment. It's hard to figure-out peoples' motives from mailing list archives. Some people (mostly on the Ubuntu "side") think that these are examples of unfairness, and some people (mostly on the GNOME "side") think that they aren't. Whatever the truth of the situation is, you have a problem right there - both "sides" are accused of acting in bad faith.

I suppose most of my point here is that biases can have an negative effect on interactions between the communities whether clear-cut documentary evidence is available or not. We're talking about feelings and perceptions here: why do some people feel alienated from GNOME when others don't think they are?

Hey Phil,

Thanks for the response. I appreciate your effort to try and clear the air here. You're putting a lot of work into keeping the discussion going.

Honestly, I really think the module inclusion decisions that you've cited are nothing to do with anti-Ubuntuism. Our release team is a responsible outfit, and the justifications given for each decision make total sense: I don't think anyone was shocked by either of them. So it's frustrating to hear those two decisions constantly brought up as examples of GNOME behaving improperly.

Why do people have the perception that these decisions were wrong? Now, that is a question worth asking! A few reasons, I think:

* Many people don't understand how GNOME works. What does it mean for a module to be accepted (or not accepted)? What are the current GNOME modules? What are the inclusion criteria? I doubt many people who feel that GNOME is closed to Ubuntu know the answer to those questions.

* There's a lot of enthusiasm for Zeitgeist within the Ubuntu community. The Zeitgeist team, particularly Seif, was publicly angry and upset about the decision that was made. And people didn't understand why GNOME had made the decision it had.

* Major Canonical figures like Jono and Mark have repeatedly made the assertion that GNOME has rebuffed attempts at contribution. I'm not sure why they have done so. Maybe they don't understand how GNOME works. Maybe they think GNOME should work differently. Maybe it's tactical subterfuge.

Why have these things hurt us? One big factor is that GNOME doesn't do a good job at explaining what the project is doing or how it works. We're primarily a development project, and we don't traditionally do user-facing communications. And this is because a) GNOME doesn't have vocal or particularly prominent leaders and b) it doesn't have the resources to employ permanent public/community relations staff.

So, to answer your question: some people feel alienated because GNOME doesn't have the resources to get its story across.

Hmm, I think I need to explain that answer a little bit.

'Some people feel alienated because GNOME doesn't have the resources to get its story across.'

When I say resources, I mean: people who can stand up and explain what GNOME is about, how it works, and give commentary on events as they happen. Those people might be 'leaders' but they might also be hired marketing/community management people.

If GNOME was able to communicate more effectively, there would be less opportunity for people to misrepresent events like the module inclusion decisions that you've mentioned, either deliberately or by accident.

(This is still Allan, btw. :) )

Just want to try to clarify things about Zeitgeist, since that's an example we hear often and as a release team member, I think it's a bad example for your point: GNOME did no reject Zeitgeist.

When gnome-activity-journal was proposed, it was rejected because, from a user experience point of view, it was not integrating correctly in the desktop. It should not be a separate application, but part of the whole shell. Since gnome-activity-journal was not accepted, Zeitgeist itself was of no use at that time (nothing else using it), so Zeitgeist was not considered. This is because we usually don't accept technologies themselves; instead we wait to have an application using the technologies.

See http://mail.gnome.org/archives/devel-announce-list/2010-June/msg00001.html for the announcement. I'm not sure why the Zeitgeist example is coming again and again, and that could be because GNOME mis-communicated on this. I'd be happy to hear any thoughts about this.

Let me point out here that Canonical is doing the right thing with Zeitgeist by integrating it directly in Unity, and that's what the GNOME community asked to the people working on gnome-activity-journal since the beginning!

Oh, and I wouldn't use Zeitgeist as an example of something from Canonical rejected since it's not a Canonical (or Ubuntu) project ;-)

Thanks for the clarification Vincent. I suppose I was more interested in the fact that some people *perceived* that part of the reason Zeitgeist was rejected was because it was Ubuntu-y (using Launchpad etc.) There must be a reason for this, whether it is justified or not.

(As I've explained in a couple of comments above, I meant to use Zeitgeist as an example of something from the "Ubuntu community", whatever that is, and didn't mean to imply that it was an official Ubuntu or Canonical project.)

If you want any patch reviewed by me, you'll have to pay. Up front. I'm not gonna apply your patches. I think $1000/line of code changed is roughly ok. I'm sure that's cheaper long term than keeping custom patches.
Because, as you so eloquently put it, I'm going to throw away some of my ideas about how this should work in an ideal world and start playing hard ball.

Or, we can do as we always did, and be nice to each other. But then we need to behave in a respectful way and avoid a behavior that would be described as ruthless.

your upstream

Thanks for the gross caricature of my argument. Clearly that's not what I'm saying. The idea is for both parties to make a few "concessions" (or "changes to established practise", however you want to describe it) in order to create a situation where everyone can operate, the hope being that this will make *all involved* stronger/happier in the long term. I don't mean "playing hardball" with each other - I mean adopting a more realistic (i.e. aggressive) attitude to the market, and resisting that attitude less within the community.

The suggestion is that "doing as we always did" may not be conducive to increasing the Free desktop's share of the market, and that some peoples' idea of what "ruthless" means should be softened. Is hosting, and then taking a cut, from a service in direct competition to one of your own services really "ruthless" (or "immoral", as I've seen some people suggest)?

How come no one is talking about Mark Shuttleworth in Darth Vader costuming? What the hell? Pics or it didn't happen, Phil.

This past weekend I was actually thinking about the contributor agreement. I'm sure we'll get to talk about it some in Toronto, but I've had a change of heart about it.

Are you contributing to Unity docs yet? If so, is there a branch somewhere?

-- Jim C

Hey, HEY! There are pictures somewhere. No conspiracy here. He drove to the venue it, apparently. Scary.

We should definitely talk about this more in Toronto - I still think the agreement is a bad idea, but I see that failing to make some concessions could severely damage the Ubuntu documentation team. We can help more users by remaining relevant.

I'm not contributing to Unity yet, but we should have a meeting about this. I think an Ubuntu Docs meeting may be in the works, so that would be a good time to discuss it.

All that aside, it'll be good to see you in Toronto! I owe you a few beers, I believe...

Hey, I talked briefly with Mark at UDS. He mentioned coming to your talk in a Darth Vader mask . . . and said that being at a college campus is one of the few places where you can walk around with a Darth Vader mask on and not have people freak out (or something like that).

Hope all is well in Physics land. See you in June!

  • 1

Log in