Re: Pre-release marketing and community management [Was: getting www.gnome3.org]



Dave Neary wrote:
> Hi,
> 
> Allan Day wrote:
> > Sriram Ramkrishna wrote:
> >> I think in this case, we want to be a buffer between devs and
> >> enthusiasts.
> 
> Ah... I'm not a big fan of buffers. I prefer trying to quieten people
> down when they're distracting. That means channelling the noise
> elsewhere, and perhaps taking a slightly drastic measure of moderating
> all posts to d-d-l for a few months.
> 
> >> In general, I want to address the frustration devs feel
> >> with having to continually defend design decisions by people who fear
> >> change.
> 
> Characterising any questions/queries/doubts/fears about GNOME 3 as
> "people who fear change" is not going to win friends and influence
> people. We need to start framing the way we talk about this issue
> correctly, because the way we talk about it affects the way we think
> about it, affects the way others perceive us.
> 
> >> But my motivation is really to get people off devs back so that they
> >> can focus on getting the design done.
> 
> So - to summarise: the problems I've seen are:
> 
> * A lot of GNOME members (be it foundation members, translators, members
> of teams not directly involved in the shell, even members of the release
> team, but also those "shrill activists") do not have all of the
> rationale & thought processes that have gone into GNOME Shell. Most
> people have not been following the shell list or the release team
> archives. So some major decisions are coming out piecemeal and are
> presented as faits accomplis - "this is the way things are, live with
> it". The shell team and release team have not been their own best friend
> in this respect.
> 
> * There appears to be cognitive dissonance between the resources that
> some GNOME people believe are there for maintenance and the resources
> that are actually there - esp. related to fallback mode - panel +
> applets + metacity.

This is something that I tried to clarify in a recent message to
desktop-devel [1]. We need an easy to understand statement here and we
need to spread it round a bit.

> * A lot of people (myself included) are worried whether we're going to
> need hardware that a substantial proportion of our user base just don't
> have.
> 
> And we can fix all these things by:
> 
> (To fill the knowledge gap:)
>  - Documenting any major design decisions made in the shell and their
> rationale, and presenting those in a nicer way
>  - Ensure that the release team is also framing things in a nicer way,
> and explaining the rationale behind things rather than just saying
> "that's the why". Notably, I think the release team should say that
> panel support is a question of manpower not policy, and it'd be nice if
> Jon backed that up.
>  - We need to start talking about all that's good in shell, what it
> brings to the table, and why it's better than what went before. Videos,
> success stories, interviews with happy users, all that kind of thing

The first priority is to get some positive marketing on the shell out
there. I'm working on the text for gnome3.org and Andreas is working on
the site. Getting that up will be a good first step.

I'm also planning to blog about some user testing I've been doing on
GNOME Shell. That will hopefully allay a few fears.

Another item that is high on my list is to turn the shell design page
[2] into something positive and explanatory. Not sure when I'll get to
that, but I'll try not to let it slip.

> (To be clear on what we want to see done but can't commit to, versus
> what we definitely don't want to see done)
>  - Help the release team and the shell team draft a "Here's stuff we're
> against" list (with justifications) and "Here's stuff we'd like to see
> in GNOME 3.0, but there's just no way we can commit to getting it done
> with the resources we have" (things like Orca) - I'd also live to see
> the GNOME project as a whole be clearer on who's involved in the actual
> maintenance of core modules and what developer resources there actually
> are - I'd estimate it at 40 to 50 full time developers, but I suspect
> I'm on the high side there.
> 
> (To allay fears of hardware compat issues)
>  - Draw up a list of graphics cards used in desktop hardware in the past
> 3 to 5 years, ordered by market share/volume of sales, and match that to
> current compatibility of free software drivers for the hardware with the
> 3D requirements of Clutter. Ideally, someone with a GNOME 2.x desktop
> should be able to run a command, get a chipset, and be able to tell
> before he installs how well GNOME 3 will work.

It'd be awesome if we had this.

We also need a realistic marketing message wrt hardware requirements.
Some people won't be able to run the Shell, and it does us no favours to
pretend otherwise. But we can still give a positive message here: 'GNOME
3 is a cutting edge desktop built not just for today but also for the
future; the GNOME project and its partners are working hard on ensuring
that everybody will be able to enjoy the benefits it brings.'

>  - Start publishing screenshots of fallback mode on chipsets that don't
> support it & making sure it's still a nice experience.

This is tricky. I'm personally unconvinced that we can have a coherent
marketing strategy and promote two desktop interfaces. Saying 'we also
have this other desktop which is really good' will just dilute the
message. There will be people who are unable to use GNOME Shell, and we
don't want them feeling too bitter but, to be honest, we *do* want them
to feel like they are missing out. GNOME 3 is a great product that they
should want to have.

> > Personally speaking, I'd add a few other ambitions:
> > 
> >  * Ensuring that those from outside the project have a positive
> > experience when they come into contact with GNOME. A bit more
> > micromanagement here would help our public relations, I think.
> 
> This is a vast task, and I'm not sure how we can make a big dent in it
> with limited volunteer resources - even doing basic communication of the
> project goals and allaying concerns people have is probably more than we
> can manage, but it is pretty much a minimum.

Yeah, it's a big job, and I'm not proposing that we attempt to take care
of the whole thing (though that would be nice :) ). The idea, as I
understand it, is merely to be more more efficient in what is happening
already and to hone our 3.0 PR skills before the big event. That
basically means sharing resources (and developing them if possible) and
experiences.

> >  * Communicating and explaining the direction of the project. 3 dot oh
> > involves some big changes and our community would benefit from some
> > positive messages in that regard.
> 
> Absolutely agree.
> 
> > Do those sound useful? 
> > 
> > Also: GNOME 3 is going to be met with criticism. We don't know how much,
> > but there's definitely going to be some. Sri made a really good point to
> > me the other day - we need well-rehearsed and effective responses to
> > those criticisms, and this kind of community management is an
> > opportunity to identify and rehearse those arguments. Maybe we could
> > work together to produce some kind of PR play sheet? Or would that be
> > taking things too far?
> 
> A FAQ will help for the most predictable criticisms, and a list of
> talking points (the "what's great about GNOME 3" list I mentioned above)
> should help us frame the messaging around the release in March, and
> everyone giving interviews or presentations should have these down pat.

gnome3.org will do much of this. Do we need anything else? (That's a
serious question - there might be.)

> That's a big list of stuff though... Who can give time, to do what, over
> the next few weeks?

You've got my to do list. :) It would be awesome if others wanted to
chip in (if they aren't already). The more we do before the release, the
better the reception will be. The clock is ticking!

Allan

[1]
http://mail.gnome.org/archives/desktop-devel-list/2011-January/msg00059.html
[2] http://live.gnome.org/GnomeShell/Design



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