Re: On the Interaction with the design team

[Dave Neary <dneary gnome org>]

Hi,

There's a lot in this email, it's worth responding to in detail (because
it gets to the heart of the matter). Reordered slightly to make my
answer more coherent :)

William Jon McCann wrote:
> I think you need to be more clear about what your goals are.

My goals are to enable the design team to work productively with the
entire GNOME development community. And this includes people who aren't
doing GNOME development full time, aren't in the same time zone as
members of the team, and people that maybe the designers don't yet know.

> Design work requires conversation, closeness, and contact. You need to
> build a relationship with the problem, the users, the stakeholders,
> the developers, and ultimately with the product. These relationships
> must be durable.

I *absolutely* agree, and this is why I am concerned with the current
situation.

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.


> Doing everything in person would be great for design work. This is one
> reason why we've been meaning to ask the Foundation to support more
> regular design team "hackfests". Using the occasional (video)
> conference call has been discussed many times as well.

Hackfests are great - they're open, and there is a natural constraint
(time, money, availability) limiting the people who can participate. For
day to day work, I really don't think it's ideal though. For hackfests
to be effective, you need most of the stakeholders present, and you need
to follow up with some really concrete reports and actions. The design
of the GNOME project affects every module maintainer - not just the
designers.

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

> 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 (and no, I don't think logging IRC is
sufficient - can you imagine suggesting that someone read the IRC logs
for a month to get a feel for why certain decisions were made?)
* 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)
* If you're not in the room, you completely miss out on any opportunity
to influence the conversation

Email has its problems - you've pointed to one. It encourages
adversarial debate (witness this thread!). Another is that there is an
"email culture" (much as there is a "forum culture") and that culture is
developer-centric (more 1980s Old Unix than 2010s New Linux).

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.

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. There would also be a way for
developers who would like help with their design problems to ask for it,
and interact with designers. Albeit with the lag time involved in
moderation.

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

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

I really don't mind if a designer and developer get together on IRC to
hash out a problem or evolve a design spec. But there should be
somewhere archived to propose that problem first, and present the
solution to it afterwards. Combined with a document sharing space like
the wiki, a mailing list with reasonable moderation configuration seems
to me the ideal place for this kind of work to happen.

I hope I've gone some way to convincing you that's the case.

Cheers,
Dave.

-- 
Dave Neary
GNOME Foundation member
dneary gnome org