RE: [libreoffice-website] [Drupal] The road ahead and missed opportunities

Hi Narayan,

I just finished reading the thread, and I'd like to come back to your
mail. You've stated some project and development fundamentals, and that
is something I'm very interested in ... how to tailer such methods and
tools. And if I got it right, you as well :-)


Am Mittwoch, den 19.01.2011, 14:52 +0530 schrieb Narayan Aras:
> Hi Italo,
>
> > Date: Tue, 18 Jan 2011 13:13:55 +0100
> > From: italo.vignoli@gmail.com
> > To: website@libreoffice.org
> > Subject: Re: [libreoffice-website] [Drupal] The road ahead and missed       opportunities
[...]
> 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.
[...]

Mmh, maybe I've missed that - but what would be one of the solutions you
have in mind?

One of the specifics of the settled parts of the community is, that many
of the activities are spread among different places. Much of the work is
even done offline, so the mailing list - although having some drawbacks
- has always been a rather reliable connection between all the people.

What I've experienced in the last years was, that the most challenges
are in the communities that start to grow - for example in countries
where education is still a challenge (and LibreOffice a key). Less
reliable power connections, almost no Internet connection, ... On the
other hand, LibreOffice has some real chances to grow there and improve
people's life.

Okay, just an example - but such constraints make it really interesting
to identify most requirements, because the workflows are "dictated" by
external circumstances. The magic is and will be, to bring that
together.

To come back to the previous question, I think that mailing list have
their drawbacks - absolutely agreed. But I think they are one valid part
of the solution.

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

Mmmh, is that tied to mailing list? When thinking about what I've
experienced so far, it is easy to "break" any tool :-) The more people
participate, the earlier it will happen. Oh, "more people", seems a
reasonable thought ...

Referring to what Italo said, I'm sure he didn't mean to formally
"approve" something - in this context.

Your postings reveal, at least I think so, that you are very familiar
with the business world. If you set up a project, it is usually proposed
to (how to say that in English?) provide acceptance criteria / project
agreement between the supplier and customer (CMMI *g*). Having that, it
is easy for both parties to verify the project delivery ... and to
roll-out the newly developed system/software/service. The agreement
helps (among requirements, goals, scope ... you know such stuff) to plan
your project in advance, to calculate the costs, allocate resources. I
think that works very very well for such organizations.

What I'm curious about, whether this works within an open-source
project. With such a huge (and incredibly interesting) task like project
infrastructure, you have hundreds of individual contributors ... whom to
ask whether the system fits to their needs? Or, how can they tell if
not?

What Italo referred to, is to get some buy-in (interest / demand / ...)
in advance - within the community. If they like it, a system will be
used ... so think of it like the preparation of the "social" roll-out
plan.

I think those who took part in any larger volunteer community, can state
some "CMMI" like essentials to bring ideas forward. It's different to
the business world.

Okay, this was a bit oversimplified - this is also true for large
organizations (most large IT projects fail, because users are resistant
against the changes). But let's keep the community topic alive :-)

[...]
> That is at the root of all trouble: 
> 1. SC does not make/approve/drive projects with WBS.

I think the SC drives the things that are vital for getting the
foundation done - this is the basis of many upcoming activities (driven
by the community). Although you might think of a very detailed WBS, here
is what currently is used ...
http://wiki.documentfoundation.org/TDF/Work_Items

And, are you sure that initiating LibreOffice, providing build and
deployment infrastructure, identifying trademarks, managing artwork,
setting up the initial infrastructure, communicating with the press,
inviting hundreds of people to join, managing volunteer availability ...
was done without WBS and thoughtful project planning? ;-)


[...]

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

That's true. But (as far as I understand) the idea is an idea, unless it
is turned into practice. And sometimes it helps to know some "pedigree"
to make sure that nothing is missed and the idea has potential. Like you
find in larger cooperations ... so called "Expert Organizations" with
people who can provide advice. Like Italo did numerous times for me.

By the way, that reminds me that I'd find it very helpful if we could do
some introduction - I'm curious with whom I speak with. What do you
(all) think? Would that be okay for you?


> 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! :) )

Oh, there is much more variance within the community :-)

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

Yep.

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

Just to get the picture ... you planned for different roles within given
processes / context / domain. Or, did you adapt some of the processes to
make them more streamlined?

I ask, because it might easily happen that you identify "translator",
but this guy will work in different contexts / or different constraint
sets. That would require some processes to be defined with different
kinds of (process) interfaces ...

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

Cool, somebody who is keen to say "personas" ... we should talk! :-)
(see [1])

> All this does not need any selling, because any professional software developer will follow this.
> This is part of the profession.

So, how many software developers are part of this community? And how
much does the project rely on the work done by non-developers?


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

Okay, so now I'm interested in how to "match" these roles to the ones to
be found in the community ... you stated the standard development team
structure.

It is true that there is some structure and (let's call it "best
practices", at least - CMMI is a collection) best practices. But in
contrast to thoroughly planned projects: involvement and interest
varies, knowledge varies, hard-to-predict schedules (mostly) ... you
also don't have "competence management", so its hard to rely on given
experience/knowledge. For example, people within the community
evolve ... a good example had been stated by Italo.

So - what I see - it's great to see some structure when addressing these
questions, but please plan for some degree of freedom :-)

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

Thinking ...

You are right, if you plan something like infrastructure, it is good to
somehow consider the different needs. On the other hand, it is unlikely
to please everyone in the very first step ... and since many of the
changes will affect a large part of the community (and many essential
processes), focusing on a few roles might make sense. Exchanging
documents / data may then be done (manually) via interfaces (exporting
files, ...).

This would - from my point-of-view - have some benefits:
      * You can optimize the processes / tools for one topic (first)
      * All other processes keep unchanged
      * If it runs for one target group, you'll get the "buy in" of
        others more easily

Still thinking ... you talked about the different tasks and the
interrelation of work. It might sound stupid, but many people here
really like to be with each other. Talking, doing something together -
in my impression, they accept some cumbersome communication media / less
efficient tools, because they simply enjoy taking part. So one of the
requirements is to keep the balance between "efficiency" and
"enjoyment". Something like: The journey is the reward.

I've talked to a lot of people, and its really fascinating what
different kinds of motivation they do have ...

[...]

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

A serious question, are you still sure about that?


Oh, and "truce" is a good point thanks Italo, and also you Narayan!

Good night, everyone! (Or day/midday/...)

Cheers,
Christoph


[1]
http://uxopenofficeorg.blogspot.com/2008/06/introducing-our-new-member-jennifer.html


-- 
Unsubscribe instructions: E-mail to website+help@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/website/
*** All posts to this list are publicly archived for eternity ***