Hi Andre, CC, *, I'm cc'ing this mail to the CC (the agenda list) since I'd like to clarify the reason why I submitted my request to the CC at all.
>From the logs, It appears to me that it has been slightly misunderstood. - But see below. While I'd prefer you to read the whole mail, you'll find the essence at the very bottom. On Sat, Apr 08, 2006 at 10:12:53PM +0200, Andre Schnabel wrote: > [...] > The problem is, that I have no idea, how to prevent our main > contributors from wasting money. It is great to hear, that a usability > studiy has been sponsored (issues based on this study are filed). But > most of the results could have been get by asking the community in a > coordinated way. We do have a lot of trainers, teachers, people who do > migration, who see how new users work with OOo, where they fail and what > the key issues for them are. > At the other hand ... a usability study is good to have. But we > (community) cannot discuss about the results, as we don't know anything > about the study (but the issues that have been filed). Exactly > [...] > PS.: For some more background information, you might read the council > log at http://tmp.janik.cz/OpenOffice.org/CC-2006-03-30.txt (relevant > discussion ist starting at 9:06:38 ) ,----[ mhu ] | but I doubt that any entity (e.g. CC) can have a veto on what another | entity (e.g. Sun, Novell, ...) is putting their resources on `---- That was not the point. Whoever creates a build/distribution for their customers specifically is free to do whatever they feel like. The point is to whether to include it into "vanilla" OOo or not. It also is not about requesting an entity to implement some stuff. The opposite is the case. Entity has created something, but the community doesn't want it at all. Especially Pavel seems to have got the point completely wrong: ,----[ paveljanik ] | who has the right to tell "this will be in 3.0"? I think only the one | who can/will do it himself. Other people can only speak about desires. `---- Some of the confusion surely arises because people did not read my post to the agenda list, but only the summary posted by Louis, which could be misunderstood. Thankefully the discussion was somewhat lead into the right direction by Andre (thalion72), but unfortunately it focused on "how can this be *avoided*" instead of "we ran into the situation, what to do in *that* case". Mh finally stated the point clearly: ,----[ mh ] | so we don't have an issue with transpareny but with conflicting goals `---- So the bottom line is: I don't think my "problem" was addressed properly yet. So I re-propose my agenda item/add it to the list of ToDo-items for CC. CC should be the "authority" reagarding OOo in that case - as it is written in the Council Proposal: ,----[ http://council.openoffice.org/CouncilProposal.html ] | II. Powers of the Council: The powers granted to the Council in order to | fulfill its purpose will be as follows: | | a. Strategic planning and resource allocation | i. Consider proposals and pass recommendations to the Leads of | Accepted Projects ("Projects") for development direction. | [...] | iii. Coordinate with Sun Microsystems on StarOffice, with | producers of other derivative commercial products and with | Open Source projects on long-term development planning issues. | [...] | c. Arbitration within the greater OpenOffice.org Community. | [...] | vi. Arbitrate disputes between members of the Community which | affect their or others' participation in OpenOffice.org. | [...] `---- The conclusions draws (more transparency of decision-taking, easy access to roadmaps/summaries,..) are all valid points that are worth to be addressed, but the absolutely don't solve the problem of a conflict of interest between the controlling entity (mainly Sun) and the community. While it is relatively easy for Sun (as "Source-Code-Gatekeeper") to block or delay features/patches from the community, it is hard the other way round. * it is _not_ about telling people what to implement/how to prioritize their tasks * it is for the situation where people already have implemented stuff, or have expressed their will to do so - but that stuff is not appreciated by big parts of the community. So how can the community reject that new/modified stuff? "No, thanks for your effort, but we don't want to have that in OOo. Feel free to use it in your $derived_product, but we don't want it to be part of "vanilla OOo." The current status is: "Whatever Sun wants to do will be done." stx12 mentioned the project guidelines that read: ,----[ http://www.openoffice.org/dev_docs/guidelines.html ] | A committed change must be reversed if this is requested by the | responsible Project Lead or by the Community Council or its delegates | and the conditions cannot be immediately satisfied by the equivalent of | a "bug fix" commit. The situation must be rescinded before the change | can be included in any public release. `---- But still the question: What does it take for the CC to act on behalf of the community. (I don't expect a request to change the feature from the PL in charge in this case, since it he is working for Sun - which is the "opponent" in the particular issue) And even that point (let the project lead decide) is not yet a "process". Surely a project-lead shall not be bothered when one single user dislikes one particular decision. So there should be guidelines on what minimum requirements must be met before the protest is even considered valid at all. An addendum to the guidelines clarifying that would be fine. Having a couple of CC members leave before the "conclusion" is kind of unfortunate as well. ################### Szenario: Sun wants to add feature/change OOo but a big part of the community disagrees. Attempts to influence the decision-taking during the specification phase were not successful/the change was not noticed at that time. The guidelines now say that the project lead or the community council can command to revert the change. Since taking action in the specification phase was not successful it is unlikely that the project lead will block that change. It may even be that there's no response or no consensus in a discussion on the relevant project's mailing-list. What are now the rules for asking the CC to block the change? It is obvious that there need to be some measure on how to decide whether it is really the will of the community (and not only a couple of "loud" individuals) that doesn't want the change. The whole point is that a decision needs to be taken: Revert the change (avoid changing it in the first place) or get it in nevertheless. Often, Project Leads are not unbiased (since employees of Sun) or discussion will not come to an end (one party says: "We want it that way", the other party says: "We want it the other way") or the leads don't even participate in the discussion. So community already has asked nicely to not commit the change to OOo, but had no success. If the guidelines now say: "Ask the leads nicely to revert the change" this is not satisfactionary and doesn't solve the problem. ciao Christian -- NP: Soulfly - The Prophet Join #qa.OpenOffice.org on irc.freenode.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
