On Sat, May 3, 2014 at 4:31 PM, Noah Slater <nsla...@apache.org> wrote:
> Modified the bit in the committer section to read: > > "Committers are expected to work cooperatively and to have good people > skills. This is more important that any other sort of skill." > > Reminder to folks: please review this. It is an exceptionally > important document, and I'd rather have commentary on it now, than > after we vote it in. > > (And yep: I am aware of the irony of pressuring people to comment on a > document that says don't pressure people to comment. But it's > important that we bootstrap these expectations properly.) > > If nobody comments in another three days, I will move this to a vote. > I have also decided that unless someone speaks up about it before > then, I'll start a thread after we vote this in asking what to do > about the chair. (i.e. Should we hold our first election, or do we > wait a year?) > > I am not sure to see the interest of these by-laws. They look redundant to the the *practices* documented inside the apache foundation documentation: https://www.apache.org/foundation/voting.html http://community.apache.org/ https://www.apache.org/foundation/governance/pmcs.html Why not simply link to them? Anyway I am not against repeating them in another place. However the current form looks a little too much procedural and complicated (looks like the by-laws inside some administrative places there), something can be done with it. I have a couple of observations and questions on these by-laws that hopefully can be addressed before any vote: - In 4.1 : the sentence "Objecting too far down the road will cause problems.", and in 4.2 "If lazy consensus is not possible, you can move to a discussion" . The passage from a lazy consensus to a discussion is not clear. How it is decided? Who is deciding it? I can see the intent here: having long discussion that goes nowhere or are blocking the project. In some others organisations, there are some practice that could limit the effects of profound disagreements (which are quite normal and expected): The place to discussion happen in a very limited time and have a deadline. If at the end of the deadline no consensus emerge, someone (generally a person chosen at the beginning of the discussion) decide to either: - propose a vote - continue the discussion on some points where some consensus can be found - postpone the idea for later - ... I think it would be good to add such procedure to the discussion handling, so any conflict can be handled gracefully with little place to the frustration. Of course we shouldn't have always a discussion,especially when the lazy consensus is needed for code. I think we should distinct some cases. Or describe how/when a lazy consensus should be the default, and other cases where the discussion should happen before anything else so the the conflict could be handled gracefully. - In 4.2, there is "Proposals should be explained clearly and come with adequate justification. Disagreements should be constructive and ideally come with alternative proposals. The goal is to reach a positive outcome for the project, not convince others of your opinion." . Sorry but I don't understand that part. How can you expect that people deeply attached to a project can't have an opinion on how it should works or be seen by the others? Also what is the point of a discussion if it's not to convince others that your idea is OK? Rather what is a bad opinion for the project (i.e. an expression of an idea) there? How do you put the limit? I think we should remove that part is can trigger to more conflict that it try to solves or make it more specific. - In 3.3 you added the notion of having "good people skills" for commiters. How do you define "having good people skills"? This notion completely depends on the culture of the people interacting in the project. I propose to remove that sentence. It suffices to say that all contributors of the projects obey to the Code Of Conduct and make the Code Of Conduct enough generic. Also If we are going to the path of defining by-laws, I think we should take this opportunity to innovate a little and make the project reflects more the community: - What about having the PMC members renewed each years by a vote of the community? So they will be the choice of the community? PMC members could be proposed during a period by the community and then a vote will happen. - The same for a chair. We could make it renewable more often. For example each 3 or 5 years. What people think about it? - benoit
