Re: User oriented release notes



Hi Claus,

On Sun, 2006-09-10 at 22:28 +0200, Claus Schwarm wrote:

>  * GNOME does not sell an operating system.
>  * GNOME does not sell computers.
>  * GNOME has no stores to sell stuff.

Certainly GNOME does not sell (but see below). Does that mean that Apple
(or Microsoft) are in a different league? Certainly not, we want to
seduce the same users with similar products. We play on the same league
and we need to be good players in our free software combined teams.

Also, it just depends on how constrained is your idea of Who Is GNOME.
Between the core GNOME stakeholders there are organizations developing
operating systems, assembling hardware, selling and deploying computers
at large. 

All they count with us and take part in the GNOME development to achieve
their goals. Or is it just a coincidence all the 2.16 progress in
performance, graphics, power management, accessibility plus the Mono
support? Do Novell, Red Hat, Sun, Nokia, Google etc pay developers to
work on GNOME just for fun, without business and marketing plans? 

We as humble marketing team can just ignore all this until the next
Feature Freeze or we can acknowledge the plans people supporting GNOME
have and try to design a GNOME strategy based on organization,
development and marketing. Doing the latter we become a better player in
this league.

> Apple formulates for ordinary users because it has products for
> ordinary users. We don't.

This is why we need a common understanding of what are our targeted
audiences. Now we haven't: some think the release notes should be
understood by grandma, some say they are mainly for developers, many
think something else. A tale starting like this can't have a happy end.
"Common understanding" means that is shared at least by the release
team, the marketing team and the board.

Just for the record, I agree with you release notes are not intended to
end users. This doesn't mean we can't have impressive release notes,
though.


>  * GNOME has no feature-based release schedule.
> 
> I think Apple's 'release notes' can look that simple because they have
> a feature-based schedule.

'Release notes' look simple when they are well done, and you can produce
good notes of any product following some simple principles. The most
basic principle is that organization, development and marketing evolve
together during all the production process. 

If someone thinks this is just bullshit, buzzwords or something not
related to GNOME, have a look at successful free software initiatives:
OLPC, Nokia 770, Ubuntu, Mozilla, OpenOffice, Mono... Add your
candidates and you will surely find organization, development and
marketing in place and well integrated.

What is <del>bullshit</del> suboptimal is to think that good marketing
can be produced as a nice envelope used by an organization to present an
already developed product. With all respects this is basically what we
are doing with the GNOME releases.

> Concerning your "vision" stuff: This looks like bullshit to me.

I type "vision" and you say "bullshit". No problem, let's use another
word: plan, strategy, perspective... what you want. If what you consider
bullshit is something else, please explain.

It is not bullshit to integrate the plans of the release team, the
marketing team and the GNOME Foundation, sharing targeted audiences and
a roadmap. We are already doing some of this, but informally and thanks
to people with several hats like Jeff, Federico or Dave. Nothing
officially agreed, nothing written, nothing people like Panos, Behdad or
myself can look at as general guidelines when contributing to the next
GNOME release.

Without a common plan the marketing team can continue improvising and
patching our mildly interesting release notes, and other marketing
products that have almost no use/impact in the GNOME community, our
stakeholders or the press. Doing this we will get better release notes
and, what is more important, better GNOME releases. 

-- 
Quim Gil /// http://desdeamericaconamor.org

Attachment: signature.asc
Description: This is a digitally signed message part



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