Re: [Freemind-developer] Draft of FreeMind constitution

[Eric L. - F. <fre...@zo...>]

Hi Dimitry,

good discussion. I think we have different level of expectations, probably
because you provide more to the project than I do, but I think we're
coming forward.

Dimitry Polivaev said:
> Hallo Eric,
>
> for a long time I had to accept a role of developer who allowed to
contribute but not allowed to speak in  name of the project and to vote.
>
> That's why I think that a system giving any active developer some rights
in the project is necessary. I would call it a "developer democracy".
This is also my point and that's why I wrote that no decision can be taken
without discusssion on the "freemind-developer" mailing list.
I didn't want to put votes on this list because in a vote there are always
"loosers", in the worst case 49.9% of them, which is not good either for
the mood of everybody. I considered that it would be better to force the
leaders to be open in their decisions, and trust on their willingness to
not hurt the developers.
I would still stand for a limitation of the number of votes, but if you
have an alternative solution, I'm open.
I think, we could say that the electorate (waehlerschaft) is made out of
the people on the freemind-developer list; this means that _this_ is
controlled by the leaders. If all discussions are on the mailing list, the
role of the leaders could be to _avoid_ votes and try to get as much of a
consensus as possible.
>
> The constitutions always give an answer to the question where power and
legitimation comes from. I believe that in case of FreeMind the power
and the legitimation should come from people contributing to the
project. I does not depend on what role they have, but should only
depend on the amount of their efforts and contributions.
>
Same expectations I think, perhaps different ways to see the solution.

> So I do not think that the proposed solution with the three project
administrators or leaders or owners can help, it is more likely to
inspire some political games, intrigues and so on. And it can not be a
task of the SourgeForge stuff to arbitrate between us and to solve our
problems.
I don't like "administrators" because it's ambiguous, and "owners" because
it's not what we want to express.
I do age
>
> I think that the constitution should clearly state,
>
> * what questions should be decided per vote of all active team members,
As few as possible, but as many as possible should be decided by consensus
of the development community (I like to stick to defined terms).

> * what decisions of the project leaders are binding to the team members,
Basically none. We don't have a police to enforce decisions, so...
I think, you need to think differently: the project leaders need to take
decisions by which they make sure that they keep the developers behind
them. For me, it's the main difference between an open source project and
a country: a politician doesn't need to care if 49.9% of the people don't
agree, they won't leave the country!
Of course, if you have project leaders who don't understand this, then you
have an issue, but then no constitution will help.

> * under what circumstances a person looses a status of an active team
member,
If the guy uses his rights to willingly hurt the project, by the project
leaders, without discussion. If it's more subtile, by consensus/vote.

> * how a team member can elected to be a project leader (administrator),
I would still want to limit the number, else too many generals, too few
"workers", and you increase the security risk: three people can coordinate
themselves, even remotely; more becomes really difficult.

> * what period of time the elected person remain a project leader.
Again, if developers' opinions are respected, I don't think that you will
have so many willing to become a leader. But I might be wrong. I think,
leaders will go away as they marry, build a house, get children, get old,
bored, whatever.

>
> My other points consider the project release cycle.
>
> I think that the problem is not that development and making releases
takes place simultaneously, but that it currently happens on the same
branch.
>
> I think that what we need is a role of "release responsible". Such
person should be responsible for merging of the new features to the
integration branch and making the release. All other developers could
continue new development, but they should not commit to the integration
branch directly. The decision what of the new features are mature enough
to be merged into the integration branch should be taken by no person
alone but by the at least one project leader together with the developer
of the new feature and the release responsible, this question should be
discussed in the list before.
>
> Actually I do not see any use in defining of the goal of the new release
before the new features or bug fixes or documentations are present.
Because you have a limit, which is not a time limit, but at least a
feature limit.
OK, mixing my phases and your vision, I think that we could agree that we
have an "alpha" phase of no more than 3 months (for example), then the
"release manager" (possibly a rotating role) takes whatever is "mature"
and makes the next release out of it, which then goes into the beta and RC
phases.

>
> My next point:
> I do not know when the constitution should be accepted. I would possible
prefer if we would agree on some useful procedures, as soon as we need
them, and produce the release. We could also define our testing policy,
because I know nobody willing to do the job of the test manager. But I
would e.g. contribute to the JUnit tests if I would see the benefits for
the project.

We haven't asked yet for candidates! I think that if we go e.g. to the
"Open Discussion" forum and ask for volunteers for the newly defined
roles, we could get people.

>
> and I would give only the time-approved rules the status of the
> constitution.
I don't understand this sentence.

I also would like to hear Chris' opinion, because else I fear that Dimitri
and myself come to an agreement, but then we need to start the discussion
all over.

Cheers, Eric

>
> Regards, Dimitry


-- 
Eric de France, d'Allemagne et de Navarre