votes and admins

[Cornelius Weiss-4]

hi devs, 

about 5 weeks ago, we quited the ugly scene about the tine 2.0 codebase. I think this is a good time to review what happend, as it's near enough to know what happend, and far enough to have a factually discussion.

Thinking about our project, and its constituions, for me the outcome of the bizarre situation is, that we have to apply a few patches to the project, to avoid having such situations again.

In my view, this are the most urgent topics:

1. eGroupWare needs a clear voting schema.

While voting is a normal and important action for a democratic project, in eGroupWare it only takes place in critical situations. I'm convinced that we wouldn't have to face situation like last month, if we had some minor technical votes in the normal egw development cycle.

It's interesting to note, that there was no single vote since we have released our consitution in March 2005.

Most pending is a list of members, which are allowed to vote. The terminus 'active developers' is not helpful as it is to vague. The absence of such a list,  builds a high barrier as every vote implies a discussion about who is allowed to vote and who not. This kind of discussion always offends those, not allowed to vote.

I think we need clear rules, who is allowed to vote. Therefore we need to change our consitution and adopt an updated version of our new members howto! These new rules must make clear at any time, who is allowed to vote without any additional discussions.

2. eGroupWare needs frequent admin votes

In any democracy it's common to have votes from time to time. Unfortunately not in eGroupWare. This leads to the current situation of having two admins which are allmost not known to the new developers. It was already stated on the core-list that this situation is dangerous, as the only remaining active admin now has a power position which was never intended by our constitution.

Currently we need to declare our distrust to the admins to have an admin vote. Thus an admin vote is always offending and not a normal action as it should be in a democracy.  This leads to disastrous situations like the one we had to face lastly.

I think we need frequent admin votes any 12 months. The admin situation must reflect the project situation, and I think frequent votes are the right tool for this.

I'll prepare suggestions for the points and ask for supporters according to our constitution. As this needs a list of 'active members' allowed to vote, I request the current admins to deliver such a list.

cu 

conny

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
eGroupWare-core mailing list
eGroupWare-core@...
https://lists.sourceforge.net/lists/listinfo/egroupware-core

[mipmip]

Connie and everyone, 

I agree we must now improve the organization. There are obvious problems and its a good time to try to solve them now the emotions are tempered.

About the Admins

The current board of Admins are voted after and because of the the former crisis we had with Mr. Jung. I think everybody wanted a new situation where the project could not be hijacked by one person. The role of the new admins was primary protecting the project. I think its time now to enhance the role of the Adminstrators. If in fact Admins are chosen for 1 year, I think it's also good that an admin forms a short term innovation plan. Though this should be concerning the project structure and not about making technical decisions.  If we implement a new Admin role, we must take time to discuss how we can protect the project against hijacking admins.

Protecting the name eGroupWare.

I also think its now really time we must create clear guidelines how the name eGoupWare may and may not be used. If we have these regulation complete, we must try to officially protect the name againt people of organizations who not resprect these regulations. If there are guidelines there can not be misunderstanding. Together we have made the name eGroupWare of worth so we must trust that eGroupWare is owned by the project. 

Branding

Personally I'm impressed by the way the TYPO3 project handles its branding: thay have a a style guide which tells everybody how the TYPO3 branding can and can not be used.  I think this could also server the eGroupWare project. See http://typo3.org/teams/design/style-guide/

About the voting and official member list

I once made a plan to handle this including the specs of an egw-app to automate parts of this. t's a bit outdated but I think there are some good thoughts in it. Maybe you would like to read it. I placed it on our website: http://www.lingewoud.nl/index.php?id=337

greets,

Pim

Op 28 jan 2008, om 14:35 heeft Cornelius Weiss het volgende geschreven:

hi devs, 

about 5 weeks ago, we quited the ugly scene about the tine 2.0 codebase. I think this is a good time to review what happend, as it's near enough to know what happend, and far enough to have a factually discussion.

Thinking about our project, and its constituions, for me the outcome of the bizarre situation is, that we have to apply a few patches to the project, to avoid having such situations again.

In my view, this are the most urgent topics:

1. eGroupWare needs a clear voting schema.

While voting is a normal and important action for a democratic project, in eGroupWare it only takes place in critical situations. I'm convinced that we wouldn't have to face situation like last month, if we had some minor technical votes in the normal egw development cycle.

It's interesting to note, that there was no single vote since we have released our consitution in March 2005.

Most pending is a list of members, which are allowed to vote. The terminus 'active developers' is not helpful as it is to vague. The absence of such a list,  builds a high barrier as every vote implies a discussion about who is allowed to vote and who not. This kind of discussion always offends those, not allowed to vote.

I think we need clear rules, who is allowed to vote. Therefore we need to change our consitution and adopt an updated version of our new members howto! These new rules must make clear at any time, who is allowed to vote without any additional discussions.

2. eGroupWare needs frequent admin votes

In any democracy it's common to have votes from time to time. Unfortunately not in eGroupWare. This leads to the current situation of having two admins which are allmost not known to the new developers. It was already stated on the core-list that this situation is dangerous, as the only remaining active admin now has a power position which was never intended by our constitution.

Currently we need to declare our distrust to the admins to have an admin vote. Thus an admin vote is always offending and not a normal action as it should be in a democracy.  This leads to disastrous situations like the one we had to face lastly.

I think we need frequent admin votes any 12 months. The admin situation must reflect the project situation, and I think frequent votes are the right tool for this.

I'll prepare suggestions for the points and ask for supporters according to our constitution. As this needs a list of 'active members' allowed to vote, I request the current admins to deliver such a list.

cu 

conny

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
eGroupWare-core mailing list
eGroupWare-core@...
https://lists.sourceforge.net/lists/listinfo/egroupware-core

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
eGroupWare-core mailing list
eGroupWare-core@...
https://lists.sourceforge.net/lists/listinfo/egroupware-core

[Frank-D]

Hi Connie, Pim and everyone,

* Maybe you would like to read it. I placed it on  
*our website: http://www.lingewoud.nl/index.php?id=337

I agree that it's  a good idea to enhance the constitution / guidelines concerning decisions, admins, votes and the use of name egroupware.

I just read most of the paper. Really nice ideas. The long text shows, how complex this topic is. Perhaps we could seperate some things:
+First to enhance the voting process. If this is done ( the decision has to be made according to the old constitution, if we want to act formally correct),
+dditional topics can be decided according to the new voting/decision rules.

Anyway to change the constitution and the voting rules is a very time consuming process, there won't be a quick decision solving all the problems.

Imho some sort of physical meeting (after some more preparation) might be a good way to prepare a new constitution, which can be voted on.

If in the meantime somebody is pressing a vote according to the old constitution (20% of active developers sf) this is another topic, because the fuss last year showed, that the old rules don't help much.
Does anybody think it's necessary to have a vote according to the old rules soon? Because imho the new rules will not be available quit a long time. Perhaps it's best to avoid this topic for some time, in order not to start the heated egw2.0 discussion again. On the other hand everybody knows, that there might be the wish to start a egw.2.0 call for a vote sometime in the future and so the best way to deal with the critical point is to name it.

regarding votes:
An important point is, who is allowed to word the question. This was one important problem last year. Questions should always be decisions about changes regarding the current status. There should always be the possibility to leave things as they are. Questions should not be worded as alternatives (besides election of course), and if they is no other way there should always be the alternative: leave things as they are. And multiple topic should not be mixed or combined in one question.

Example:
Good question:
Should we exclude Person A from the mailingslists, because he's a naughty boy?
Bad question:
Choose one alternative:
+Exclude person A form the mailinglist.
+Exclude him form mailingslist and sue him.

Good Question:
Should we take some prototype code base (for some app, for a new major release) as new official app/version)
Bad Question:
Choose one:
+Take new app as official app and delete all old apps from repositors.
+Don't take new app

Good Question:
Do we want to make an area for a new prove of concept for some technology in svn?
Bad Question:
Choose:
Desicion, that we will use some new code in the future, which is not available yet.
Decision, that we will never ever use this technology in the future.

All similiarities of this examplse to events in the past are only accidental ;-)


Best Regards Frank

[Cornelius Weiss-4]

Hi Pim, 

last monday i wrote two concrete proposals and stated that I want to call for supporters for them according to our constitution.

I'm totally with you, that there are many more topics to resolve. But we have to solve one after the oder. (Your words :-) )

So please admins, deliver a list, so that we can vote on the topics.

If you like to skip the 'call for supporters for a vote' phase, just two of you must comply to vote on the topic. But nevertheless we need a list of voters.

cu

conny

Am 29.01.2008 um 12:25 schrieb Pim Snel:

Connie and everyone, 

I agree we must now improve the organization. There are obvious problems and its a good time to try to solve them now the emotions are tempered.

About the Admins

The current board of Admins are voted after and because of the the former crisis we had with Mr. Jung. I think everybody wanted a new situation where the project could not be hijacked by one person. The role of the new admins was primary protecting the project. I think its time now to enhance the role of the Adminstrators. If in fact Admins are chosen for 1 year, I think it's also good that an admin forms a short term innovation plan. Though this should be concerning the project structure and not about making technical decisions.  If we implement a new Admin role, we must take time to discuss how we can protect the project against hijacking admins.

Protecting the name eGroupWare.

I also think its now really time we must create clear guidelines how the name eGoupWare may and may not be used. If we have these regulation complete, we must try to officially protect the name againt people of organizations who not resprect these regulations. If there are guidelines there can not be misunderstanding. Together we have made the name eGroupWare of worth so we must trust that eGroupWare is owned by the project. 

Branding

Personally I'm impressed by the way the TYPO3 project handles its branding: thay have a a style guide which tells everybody how the TYPO3 branding can and can not be used.  I think this could also server the eGroupWare project. See http://typo3.org/teams/design/style-guide/

About the voting and official member list

I once made a plan to handle this including the specs of an egw-app to automate parts of this. t's a bit outdated but I think there are some good thoughts in it. Maybe you would like to read it. I placed it on our website: http://www.lingewoud.nl/index.php?id=337

greets,

Pim

Op 28 jan 2008, om 14:35 heeft Cornelius Weiss het volgende geschreven:

hi devs, 

about 5 weeks ago, we quited the ugly scene about the tine 2.0 codebase. I think this is a good time to review what happend, as it's near enough to know what happend, and far enough to have a factually discussion.

Thinking about our project, and its constituions, for me the outcome of the bizarre situation is, that we have to apply a few patches to the project, to avoid having such situations again.

In my view, this are the most urgent topics:

1. eGroupWare needs a clear voting schema.

While voting is a normal and important action for a democratic project, in eGroupWare it only takes place in critical situations. I'm convinced that we wouldn't have to face situation like last month, if we had some minor technical votes in the normal egw development cycle.

It's interesting to note, that there was no single vote since we have released our consitution in March 2005.

Most pending is a list of members, which are allowed to vote. The terminus 'active developers' is not helpful as it is to vague. The absence of such a list,  builds a high barrier as every vote implies a discussion about who is allowed to vote and who not. This kind of discussion always offends those, not allowed to vote.

I think we need clear rules, who is allowed to vote. Therefore we need to change our consitution and adopt an updated version of our new members howto! These new rules must make clear at any time, who is allowed to vote without any additional discussions.

2. eGroupWare needs frequent admin votes

In any democracy it's common to have votes from time to time. Unfortunately not in eGroupWare. This leads to the current situation of having two admins which are allmost not known to the new developers. It was already stated on the core-list that this situation is dangerous, as the only remaining active admin now has a power position which was never intended by our constitution.

Currently we need to declare our distrust to the admins to have an admin vote. Thus an admin vote is always offending and not a normal action as it should be in a democracy.  This leads to disastrous situations like the one we had to face lastly.

I think we need frequent admin votes any 12 months. The admin situation must reflect the project situation, and I think frequent votes are the right tool for this.

I'll prepare suggestions for the points and ask for supporters according to our constitution. As this needs a list of 'active members' allowed to vote, I request the current admins to deliver such a list.

cu 

conny

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
eGroupWare-core mailing list
eGroupWare-core@...
https://lists.sourceforge.net/lists/listinfo/egroupware-core

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
eGroupWare-core mailing list
eGroupWare-core@...
https://lists.sourceforge.net/lists/listinfo/egroupware-core

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
eGroupWare-core mailing list
eGroupWare-core@...
https://lists.sourceforge.net/lists/listinfo/egroupware-core