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

First of all, thanks for taking the time to answer.

On 01/19/2011 10:22 AM, Narayan Aras wrote:

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.

Well, note that the mail lists cannot distinguish between "approved" tasks, "unautorized" tasks and "new 
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).

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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.

I hope this makes things more easy to understand.

Ciao, Italo

Italo Vignoli - The Document Foundation
Mobile +39.348.5653829 - VoIP: +39.02.320621813
Skype: italovignoli - GTalk:

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.