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
> 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 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
> not?
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
> plan.
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.
> http://wiki.documentfoundation.org/TDF/Work_Items
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 counterpart.
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!
Regards,
Narayan
--
Unsubscribe instructions: E-mail to website+h...@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/website/
*** All posts to this list are publicly archived for eternity ***
