> > 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.
> Can we say that the SC did not receive enough inputs to correct these
> mistakes? We have gone through months of 18 hours per day work schedule
> and we have probably been less responsive than we should have been. But
> it should be clear that we are volunteers with a professional and a
> personal life, and we are far from being perfect.
It is the other way around: SC has not communicated its vision properly/enough.
Worse, SC has also not responded to the ongoing chatter in mail lists to set
things right periodically.
While SC was COMPLETELY absent from the battlefront, the volunteers rallied at
the mail list, and charted the course.
Volunteers are not androids who will stay in cupboards till needed.
They too love the excitement of creating something that was never done before.
Why rap their knuckles for it?
And where does the wisdom lie- In insulting/sacking such volunteers or in
letting them do it?
Charles delivered the same ultimatum to the web team that he probably heard
from Oracle.
How are we "liberated"? How are we better?
And why does SC feel threatened by this voluntary enthusiasm? You should be
thrilled!
> 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.
>
> This is true.
>
> > Otherwise Sc can NOT keep track of which mails are within scope and which
> > are extraneous.
>
> This is true as well.
>
> > Even with this, SC can NOT prevent members from making new proposals.
>
> I think that here lies one misunderstanding. New proposals are welcome,
> but they should consider the history of the project and start from here
> (therefore, if the new proposal diverges from the history, then it is
> important to get consensus before going forward).
That's the most inefficient way to work in a loosely formed organization.
It would be better create a project for each approved proposal, and run it
strictly within its scope/budget/time.
Like how any software project runs.
Then the SC can be in control. And believe me no one will mind.
> As I said somewhere: evolution and not revolution. We can, and should,
> change radically some habits, but it takes time. Sometimes, it takes twice
> the effort.
Correct, and it is the volunteers who are straining the most!
Let SC be supportive at least, if not leading the wave.
> > Either lead, be lead or get out of the way! Sleeping at the helm is not a
> > viable option.
>
> We were not sleeping but doing other things. Yes, this was a mistake.
Well, as the volunteers see it, SC had abandoned post. That's it.
As a marketing professional, you would appreciate that it is the public
perception that matters, not the reality.
Now SC should be gracious and gain respect of public through generosity and
magnanimity, not through coercion.
> > Look, pedigree is useful in a dog show, not here.
> > I think we should focus on merit of an idea, not WHO proposed it.
>
> Of course, but sometimes experience helps. In sever years, I never
> talked about my background, and in this case it was just an example.
> Someone has to judge the merit of an idea, and experience allows to have
> at least a more informed judgement.
Sorry- If we hope to create a truly meritocratic society, we should actively
mask the sources.
> Stakeholder is a common word of my profession, and I understood roles as
> well. The problem is that the website strategy was to have the web as
> the entry point, and this was a mistake.
>
> History tells us that the web is not the entry point to the project.
> This might change in the future.
In fact, almost all operations would be achieved through internet.
Recruiting volunteer is a small part of it.
What about issue-tracker? Configuration management? Release management?
Project management? Documentation?
These activities would also be through the website.
> I would dare to say that most volunteers today participate without ever
> accessing the web site. Again, this might change in the future, but I do
> not see this happening for many people.
>
> For instance, in Italy there is a gentleman (nickname Martello, which
> means Hammer in Italian) who is generating on a monthly basis a PDF FAQ
> document based on the newsgroup discussions (over 3000 pages now) and
> has never accessed the web site.
>
> This is just an example.
There is some misunderstanding. Website does NOT mean Drupal (or SilverStripe
for that matter).
The complete software development would be done through the website.
In fact, parts of the website would be running on different software, such as
bugzilla.
> So, if we define stakeholders we have way more than 23, and some of them
> interacting in a weird way with the project.
>
> For instance, the Italian association (I am the president) has a web
> site which is never going to be officially connected to TDF and/or
> LibreOffice.
Even assuming that there are some independent sites on LibO, how does that fact
impact our strategy?
The users of that site are simply not OUR stakeholders.
> I think that the basic mistake (and the SC should have shown the problem
> at the very beginning, having a better management of the web project)
> has been to conceive a web site which was departing from the background
> of the project without offering at first a parallel path, and later a
> convergence path.
Yes. The leaders are supposed to have a vision.
Here the web team has developed a vision on its own.
The challenge for SC is to show them a better vision, belated as it may be.
> > 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.
>
> But you cannot force people to use the web site for their tasks, either.
> TDF brings together developers and users, and you cannot build the
> project assuming that everyone will accept to use certain tools. I use
> my own tools, and I am not going to change them because there are other
> tools available on a web site, because this would disrupt my habits and
> interphere with my professional life (as I use the same one for both).
Of course!
Finally, users gravitate towards the better tool.
We will definitely settle this through dialog with each user class.
> > 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.
>
> Again, this is a misunderstanding. The idea is completely new for the
> history of the project, and as it represents a total departure from the
> history has to be sold. We have already seen a central infrastructure
> failing completely (CollabNet) and creating a huge amount of
> frustrations and misunderstanding.
>
> We have already seen many "this is going to be perfect for you" stories
> to believe them once more.
Why do we have this phobia about "new" things?
Are we going to say "look here, I wouldn't try LibO if I were you. You never
know with them newfangled things!"
What is good for others is not good for us?
And why are we afraid of using open source things that have already large user
base and large communities?
Why don't we try it out? The web team can easily set up a pilot copy.
Why does SC not take a lead here, instead of freezing with fear? FUD working in
reverse??
Even OOo community changed their Configuration Management system after 9 years.
It only shows we need to change with the times.
And fortunately, there is no "history" attached with LibO community, right?
So we have this wonderful opportunity to use the latest and most powerful tools.
> SC mistakes were not to make this concept completely clear from day one,
> and to overlook the development of the web site to the point that the
> development itself has gone out of control.
>
> Web team mistake has been to assume that any solution would have been
> accepted independently from the level of departure it was representing
> from the history of the project, and to assume that we web site could
> become the cornerstone of TDF.
When leaders abandon post, and don't respond to calls, it is not a "mistake".
It is a "blunder".
And things get worse when coercion is used to control the dedicated people who
tried something on their own.
Why doesn't SC sell the road map and milestones as a damage-control exercise?
Still, I wouldn't say the project has gone out of control.
Which specific road map or milestones are being violated/missed here?
Regards,
Narayan
--
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 ***
