Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index

Hi Italo,

Date: Tue, 18 Jan 2011 13:13:55 +0100
Subject: Re: [libreoffice-website] [Drupal] The road ahead and missed opportunities

On 1/18/11 12:26 PM, Narayan Aras wrote:

Then I volunteered to collect the stakeholders requirements.
The 23 roles were identified on this very mail list.

I have seen mentions of these "23 roles" many times, but I have not seen 
a list where they are described in detail. It looks like they have been 
developed without even asking the SC members - or the group of the 
founders - if this was the right approach.

The whole work was in accordance with SC's decision.
(see the links provided by Michael and others.)

Can I help it if the MC does not read the mail list?

BTW I have consistently maintained that mail lists are not suitable to capture such matters.
There are easy solutions available. But SC is not interested.

So SC has to blame itself for (a) not reading the mail list. and (b) not installing proper tools.

I am not a web site expert, but I am a member of the SC and in addition 
I am the one coordinating marketing (you might complain about this, but 
I got the trust of the founders based on seven years of activity inside 
the OOo community). In order to approve an approach, you have to "sell" 
it before even starting to work at it.

Well, note that the mail lists cannot distinguish between "approved" tasks, "unautorized" tasks and 
"new proposals".
Further, within an approved project, you cannot control each and every aspect that is proposed.
This is an inherent weakness of mail list.

If SC wants to control each minutest step,  the only solution is to launch a formal project. 
Further, that project has to be broken up into tasks and sub-tasks (This is called "WBS"= Work 
Breakdown Structure) 

In other words, the SC has to maintain various approved projects, each with a detailed structure.
Only then we can talk about whether any step is approved or not.

Otherwise Sc can NOT keep track of which mails are within scope and which are extraneous.

Even with this, SC can NOT prevent members from making new proposals.

That is at the root of all trouble: 
1. SC does not make/approve/drive projects with WBS.
2. SC misses the ongoing progress on approved/unautorized/new proposals.
3. Then SC wakes up one fine day and starts questioning the discussions and starts reversing the 

Either lead, be lead or get out of the way! Sleeping at the helm is not a viable option.

When I have entered the OOo community I told the members about my 
experience (at the time, 23 years in IT marketing, as an executive VP of 
a very large corporation and then as a consultant, plus 12 years as a 
professor in Italy and the US - summer courses - where I have also 
obtained three master degrees - all summa cum laude - in communications 
(marketing and media relations) and journalism, which in general can be 
considered as adequate credentials for an OOo marketing contact), but I 
was asked to start working at translating some documents (which I did 
translate as it was a very easy task).

When Davide Dozza, the Italian OOo maintainer, saw the quality of the 
translations, then I was allowed to start working in "real" marketing. I 
had to "sell" myself, although I had very good credentials.

I do not mind about my background (other long time members of the OOo 
community can confirm they have never heard about it until today) as I 
do like to be respected for what I do and not for what I have studied. 
Communities have their non written rules, and there is some learning 
curve (as in any other activity).

Look, pedigree is useful in a dog show, not here.
I think we should focus on merit of an idea, not WHO proposed it.

In any case, most volunteers are not vying to become SC-members.
At least those people should be excused for not advertising their lineage.
I am very interested in understanding:

1. Why you decided to create "roles" (it might be a silly question, but 
when you deal with people different from you I have learned that there 
are not silly questions)

@the word "roles"
No this is a good question, and I am sure everyone else on the SC knows the answer already, because 
they are from software development community (you are the only outsider! :) )

The original word I used was "stakeholder" which means anyone who has an interest in the product.
This term goes beyond the "users".

But later someone suggested that a given team can act as multiple types of stakeholders.
So I changed the term to "role" to avoid confusion.
The idea is that any person/team can play multiple roles; and there may be churn in how these roles 
are played.
The website should be flexible enough so that its interface changes to accommodate any role-mix.

@Is this a standard concept?
Yes.  Refer to CMMI-DEV 1.3 (  pp.337-352, 385-404.

A MUCH simplified model is as follows:
For any software, we start with identifying the stakeholders.
Then we find the specific requirements of each stakeholder (called "elicitation").
Then we check if there are any conflicting requirements and find a balance (trade off).

Later, during design process, we decide which part of the product will satisfy which of these 

For website design, there are special techniques: 
We classify users in "demography" (race, age, sex, etc.) because their habits may be different. 
Then we model typical customers through "personas".
This lets us design the perfect website that exactly meets the needs of all users.
All this does not need any selling, because any professional software developer will follow this.
This is part of the profession.

2. How you decided to define these "roles"

Most roles were from standard software development team structure.
Refer to PMBOK (project Management Body of Knowledge) for details.
Again, all people from software development community are supposed to know this.
3. How you got to the number of "23 roles" (my perception is that 23 
might be way too many, but I might be wrong)

Well, this is a large project, with a large number of stakeholders.
I cannot remove some of them to bring down the number.
Although some of the roles can be combined, their specific needs cannot be ignored.
Each role-player would be using the website for his daily/weekly/monthly tasks.
All this work is interrelated: Someone's output is used by someone else.
So we cannot skip roles.

4. Which benefits bring these 23 roles to the web site, and to the 
community in general (being the web site an expression of the community 
and not an independent entity)

For an example, please see Launchpad. Ready demos are available.

Again, the SC members are aware of its importance.

I think that once these five questions (maybe silly ones, as I said) get 
an answer and are fully understood by the community (the founders and 
the SC are supposed to be the first community representatives even if 
sometimes their behaviour might look different, but everyone should 
remember that we are all individuals with our own pros and cons, and our 
specific way of expressing ourselves, independently from our role) then 
we might have a better understanding of the beauties and the advantages 
of a different (and improved) web site).

I think that the main fault of everyone in this specific domain of the 
web site (including SC members) was to overlook the web site problem and 
leave it unmanaged.

I look forward to get the answer to my questions. Ciao, Italo

Thanks for trying to bring truce, but all software development guys already know what we mean.
The idea is neither new not does it need to be sold.
Unsubscribe instructions: E-mail to
List archive:
*** All posts to this list are publicly archived for eternity ***


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.