Hi Christian, *
I set [EMAIL PROTECTED] to cc, it seems, we (the council) got your points
wrong. And I agree to your subject and some of your comments, that
Project-Guidelines are not applied very well in practice.
For the council members - please read Christian's post to the agenda list:
http://council.openoffice.org/servlets/ReadMsg?list=agenda&msgNo=3243
I'm tryng to quote only the most relevant points here.
Christian Lohmaier schrieb:
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.
...
[...]
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.
...
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
`----
....
The conclusions (of the council meeting) 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.
.....
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.
For the current problem (implementing issue 61679) we seem to run in the
szenario, that Christian describes.
When the issue was seen by community, comments have been made at the
issue, that it's implementation would not help new users, so it should
rather not be implemented the suggested way. The outcome was, that the
issue was first targeted from 3.0 to 2.0.3 after some more comments (or
rants) at the issue, it was targeted to 2.0.4.
Although we collected arguments from users and sent them to the Word
Processor mailing list we got no answer at all for about 5 days now:
http://sw.openoffice.org/servlets/ReadMsg?list=dev&msgNo=1238
Please keep in mind, that (germanophone) community has collected user
arguments, summarized them, provided them and sent them the suggested
way. So it is visible, what our suggestion is based on.
At the other hand, we got no answer .. or only "we have a usability
study" without knowing, how it was done, what the real outcome was ...
For the moment I'd suggest we inform project leads, that they need to
accept such request and should comment. The next step was, what was
suggested during discussion:
[10:06:43 AM:] louis_to: so, to summarize, that we request that project
leads post a notice on their projects (technical projects, esp.) about how
people can contest decisions as the guidelnes specify. (We have not added
more to transparency of actual decisions, btw, only a way to contest made
André
decisions.)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
