Hi Italo,
> Date: Tue, 18 Jan 2011 13:13:55 +0100
> From: [email protected]
> To: [email protected]
> 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 things.
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 (www.sei.cmu.edu/reports/10tr033.pdf) 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 needs.
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 [email protected]
List archive: http://listarchives.libreoffice.org/www/website/
*** All posts to this list are publicly archived for eternity ***
