Re: On the Interaction with the design team

Dave Neary wrote:
> By working real-time, you are preventing a relationship from being built
> beyond a small group of people. Those people work closely together, but
> have the appearance of a closed tight-knit clique from outside the
> group. There is no transparency about what the design team is, who has
> what skills, etc.
> Many stakeholders and developers who have design problems do not have
> any relationship with the design team at all.
> This is the problem I think we need to solve.

We're a small team - we can't solve every design problem in GNOME all at
once. :) (Just saying.)

> > But relationships are hard to do online. Hard to do
> > long distance - more difficult the farther you are from that
> > reassuring touch.
> This is a pretty good problem statement for free software development in
> general. I think we can agree that the key challenge that most free
> software projects have had to overcome is how to build durable
> relationships online. And we haven't always done it perfectly. But we
> have at least 20 years of experience to fall back on when considering
> how we might do so.

Design in the open is a new challenge, of course...

> > Is IRC perfect for this? Certainly not. I didn't use IRC at all until
> > just 4 years ago - and I still curse at it.  However, it is still much
> > closer to a conversation than is email. The architecture of email
> > encourages argument not agreement. Exchanges are volleys. Too much
> > tactics and too little strategy. It still has a place in the world,
> > obviously, but not in the tender stages of a design process.
> Let me be clear: real-time communication has a role. But it fails in
> three key points:
> * There is no record of the culture for newcomers and other members of
> the community to consult 

I wrote a contribution guide which was intended to help with this issue
[1]. Let me know if you think it could be improved in any way.

> * There is no clear way for a newcomer to contact the team, or to know
> who the individuals in the team are (related to the lack of a record)

We have a list of which designers are involved in which projects on the
wiki [2]. It's not up to date or complete, but it's something.

> * If you're not in the room, you completely miss out on any opportunity
> to influence the conversation

I would expect the relevant people to be in the room or be informed
afterwards if a significant decision is made. That's the way it works on
the design projects that I'm involved in.

> We do need to create an environment where designers can feel free to
> brainstorm, create, and design. We also need a way to have a feedback
> cycle with developers.

Feedback is a separate problem to enabling participation, no?

Doing more in terms of community relations is something that I'd love to
do more of and I have some ideas about it. Time is always the limiting
factor, though.

> The compromise solution which I proposed last year (off-list), and which
> a number of people did not think was a good idea, was to have a mailing
> list whose membership was moderated. Archives would be public, but only
> designers & some key developers would be members - all other email to
> the list would be moderated.
> This addresses part of your concern - the argumentative, confrontational
> nature of GNOME mailing lists - while also allowing an area where people
> outside the design team can see who is who, who does what, and get a
> feel for the culture of the team.

A moderated list might be a good way of allowing people to make contact
with our designers (not a massive problem, but it's a problem). It might
also be useful for passing the odd message around. I'm not convinced
that a list would provide a good way to enable people to participate
more easily, however - and isn't that the most important requirement?

So I'm not thoroughly opposed to your idea, but I'm not massively
enthusiastic about it either. But it's not me you've got to convince -
it's the others you expect to use this list. There's no point in setting
up a design list if there aren't any designers subscribed to it.

And really: is writing a message to ddl the best way to make this

> > We don't have the perfect solution but I think there is now sufficient
> > proof that GNOME design is flourishing despite it.  At some point, I'm
> > sure, this want will motivate an inventor and we'll be even better off
> > for it.
> I am sure that I am not alone (because others have told me, and said so
> right here) when I say that I don't think the current situation is
> sustainable. A small group of people are making profound changes to the
> project on an unarchived IRC channel.

Well, designers don't make changes to GNOME on their own. ;)

This issue is largely one of perception and the need for better
community engagement, in my opinion. We need to take the time to talk to
people in the community and explain what's happening. That takes time
and resources, of course.

> Several people have brought up
> questions, concerns and issues here and elsewhere about this way of
> working, and those have mostly been dismissed by the individuals concerned.

It should be clear from this thread that those of us in the design team
take these issues seriously. We're actually rather passionate about
doing design in the open (I certainly am).

> I would really like to encourage a design culture in GNOME, and a real
> collaboration between GNOME developers and designers. I would like to
> see GNOME recruiting new designers & documenting the design principles
> guiding choices in the project.

I share all of those ambitions, and I expend a lot of time and energy
trying to make them a reality.

> I don't think that will happen with the
> current set-up, and I fear that if we continue unchecked we'll reach a
> breaking point.

Nobody is pretending that GNOME design is perfect - there's a lot of
room for improvement. Let's not get all doom and gloom though! We have a
great design community comprised of a bunch of talented, enthusiastic


IRC: aday on

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]