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

Good points (as always), Christoph!

This is exactly what we expect from SC: Know the pulse of the community and guide any effort.
Tailoring by SC is essential.

I know I read the "bare act" from CMMI and PMBOK, but that's not how we should/would be applying it.
Any corporate project and community project would differ. We know that.
Even within the corporate world also the implementation is not that strict. We also know that. :)

Any implementation must be tempered with realistic assessment of how comfortable the target user 
would be.

So the idea is not to build an ivory tower and believe everyone will be happy living there.
The "Requirement Elicitation" phase will take care of the actual needs (and unmet needs that new 
tools can achieve).

Just think why develop LibO when OOo is already there for the same user class.
Is it the act of defiance of a few misfits at Oracle, who were thrown out for being uncooperative?
No I'd like to believe it was for a higher purpose; a long-term vision.
When the project is driven with loftier principles, it is supposed to yield a superior result.

It's the same thing with the website too!
And again repeating myself, I am CMS-neutral.
The requirement elicitation from stakeholders has nothing to do with what CMS is used.

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

Actually I used YOUR post at the mail list to suggest a possible solution.
It's not a ready-made module from any CMS, BTW.

And this very case illustrates the point:
First I missed your post, and had to actually Google all your posts and dredge through each post.
When I found the right one (BUT under a wrong title), I put up a suggestion.
Then it was SC's turn to miss that.

Even to dig it up would be an effort now.
How long do we carry on with this farce?

The mail list is like throwing words in the wind. or tunneling in sand.
Everything is lost almost instantaneously.

So are you convinced now?

It is the "ease of offline access" vs. "searchability, collation of ideas, permanence".
Pick one. Or the other three.

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

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 find that a little strange: We care about a few kBs for the contributors.

A dropped line is not a big catastrophe.
It's only a mail list, where a missed mail is as good as gone anyway.

Compared to number of contributors, the number of users is multifold. 

Each user is facing exactly the same internet problem.

And he has to download several hundred MBs each time over low bandwidths.

The consequence of broken link is catastrophic.

And yet LibO requires full download for each version.

Immediately after taking over, Oracle made OOo upgradable.
Oracle cares about this. We don't. 
We pander to the contributors instead.
How much time was devoted to making LibO upgradable with patches?

And it serves to block out the new tools. (No offense.)

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

Let me explain:
When someone (from a large pool of volunteers) posts a mail-
1. He may not be talking about an SC-approved "project"
2. He may be proposing something altogether new, which has an impact on policy.
3. he may be planning out the implementation in line with an SC-approved project 
4. His proposal may violate/transgress our code of conduct

In this chatter, any deviation from SC's goals/policies cannot be easily spotted or regulated.
SC will be reduced to censuring each post, or react belatedly as in the website case.

Worse, when the Sc reaction comes, the proposer will not know who's responding.
In near future, there will be a plethora of committees apart from SC. 
They will have their own domains for approval and controlling.
How will a mail list manage all this?

And how will past decisions stay in record for everyone to see?

If you really want low entry barriers for newcomers, you have to build a meta-model.
You cannot expect the newcomer to go through tons of mails and imbibe the culture.

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

The approval can be quick and informal -- That's for us to decide. 
But a more important (and neglected-) aspect is sharing of the vision and goals.

Volunteers are already complaining that SC dictates what to do, and what NOT to do.

That is only a perception issue, because SC has not shared its vision and strategic plans. 
So the volunteers don't feel they are empowered.

So share the vision. Share the roadmap and milestones that go toward that vision.
Then launch initiatives (projects) for a defined milestone/goal.
Get volunteers on board.

Then it will not look as if SC drives everything according to its whims and fancies.

Without a cascaded goal system, how will the leader justify the project?
How will the small goals be aligned with long-term goals?
How will you minimize waste of resources?
How will you prevent spurious code from getting added to the repository?

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

That's the very idea behind requirement elicitation.
And you know I have tried "back door diplomacy" to find the opinion leaders in each field. :)
That exercise has not even started in earnest. We need some patience.
That is at the root of all trouble: 
1. SC does not make/approve/drive projects with WBS.

Yes, that's what I am looking for as a start. 
The "WBS' may not have more details (This really depends on the scope of work and the team's 
collective preference). Further, the Gantt chart (if any) may be in terms of days, not hours.
In other words, the community tools would NOT be so exacting and demanding as the corporate 
After all, the developers would hate being shackled while working on their hobby.
So the PM is just a light process to keep a rough track of what's happening.
It's not the full industrial-strength version.

BTW note that this is the first time I am looking at that chart.
It does look like an abandoned idea: Why is the status column blank and dates not revised?
The wiki is full of such good work that is not "live" any more.

This page should have presented itself to me (a newcomer) in the beginning.
A newcomer should not need a personal guided tour by an SC member.
That is what we mean by "low entry barrier", right?

Did SC consider this as a goal? How do you keep the faithful together?
A revised AI for the website will take care of this.

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?

No the roles are just a blackbox concept. Think of UML use case diagram.
At this moment, we only know the users. We do NOT know the use cases.
We want to survey how the current system/tools work.
The idea is NOT to offer a shining thing from Silverstripe/Drupal gift box.
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 ...

That is what we mean by "use cases". 
A given user may have several use cases (scenarios) and trouble spots.
The new CMSs may not solve all of those problems. There are no magic bullets.
But he would be definitely much happier with something made with his own ideas and wishes.

Nothing will be forced down his throat.

Cool, somebody who is keen to say "personas" ... we should talk! :-) (see [1])
Nice! That was two years ago... Hope something useful came out of it!

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

Of course! The developers- the real backbone of this community - will be typically having a day job.
Their own stressful life (and unpredictability) has to be accounted for. 

We simply cannot put the usual "8 hours per day, 5 days a week" formula in the MS Project.
Resources would go away for days on end. They would lose interest and drop out.
Thus the delivery commitments would be only approximate, and subject to heavy fluctuation.
Again, the project tracking will not help these factors.

[...] @23 roles:
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, ...).

Yes, Each group are the web team's internal customers.
We have to cater to them (not the other way round). :)

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

Each group is a separate customer. So it is not sequential.
Plus we have to keep in mind the interdependency!
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.

You said it! It should be fun working in LibO. 
Creative freedom is part of it. Ease of work is another.
A third part is promoting camaraderie amongst the group members.

That's the challenge!

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.