Re: [xwiki-devs] [VOTE] Create a new private list for committers for non public topics + use it for voting committers

Hi Guillaume, Your arguments are very valid and I've considered them a lot before sending my vote. Actually to be perfectly honest, I've been on the fence on this question for several years now. However I've been slightly more in favor of the private list idea lately (I think due to the fact that I've proposed quite a few committers. It's probably harder to understand if you haven't done so). See below for more details. On Oct 10, 2011, at 4:04 PM, Guillaume Lerouge wrote: Actually this questions arises relatively frequently in open source communities (be it apache or elsewhere) and I've seen it raised several times in my 12-13 years of open source. The other reason you haven't experienced may be because you've not proposed committers yet. You haven't had to individually contact every one to make sure the vote will get accepted, convince people offline that it's a good choice, etc. Apparently you call this transparency… :) I don't. How many times have you seen people voting with restrictions on new members or even with -1? Answer: none How many times have you seen people voting with restrictions or even -1 or topics other than member voting? Answer: frequently Why? Because people are respectful and tend to shy away from telling someone in their face that they just sucks, or that they're too junior even with 15 years of experience… ;) My proposal is just to make voting a new member a real voting process. Actually you're forgetting one part which is one issue IMO. Let me give you an example. Imagine that I've seen that XXX has a good level of understanding of the xwiki platform and that he's submitted several patches in the past and I think he would be a good addition to the committers to the xwiki project. Right now I have 2 choices: * Send a VOTE email on the devs list. Two possibilities: ** he's accepted. Now I need to ask him if he's interested. If not, then the vote was for nothing ** he's not accepted. Now XXX sees this. Maybe someone said that he needs to provides more patches before he can be accepted or that his patches have some issues, etc. On one hand it's good since he now knows what he should improve, OTOH depending on how well-phrased or not the negative answers were, he'll feel let down and make simply stop participating to the project completely * Ask the potential committer if he'd be willing to become a committer (with all the committer duties - see committership on dev.xwiki.org). ** if he says yes and he's not accepted that sucks since you had increased his expectations and he's going to feel he's been let down or that his work is not appreciated, etc ** if he says no, then no issues. No vote is started. However others don't know about it. The solution I'm proposing is to send a mail on the committers@ list. If he's voted ok then we can contact him and ask him if he's interested in becoming a committer. If he's voted down no harm is done. Now I've always hesitated on this topic since I've seen arguments on both sides of the fence. I also agree that ideally it would be best done in the open if it could work but it doesn't IMO because of the way human relations work. People don't tell other people what they think of them in front of their face. Here's what Karl Fogel says in his book: "Producing open source software: how to run a successful free software project": http://producingoss.com/en/consensus-democracy.html " […] The voting system itself should be used to choose new committers, both full and partial. But here is one of the rare instances where secrecy is appropriate. You can't have votes about potential committers posted to a public mailing list, because the candidate's feelings (and reputation) could be hurt. Instead, the usual way is that an existing committer posts to a private mailing list consisting only of the other committers, proposing that someone be granted commit access. The other committers speak their minds freely, knowing the discussion is private. Often there will be no disagreement, and therefore no vote necessary. After waiting a few days to make sure every committer has had a chance to respond, the proposer mails the candidate and offers him commit access. If there is disagreement, discussion ensues as for any other question, possibly resulting in a vote. For this process to be open and frank, the mere fact that the discussion is taking place at all should be secret. If the person under consideration knew it was going on, and then were never offered commit access, he could conclude that he had lost the vote, and would likely feel hurt. Of course, if someone explicitly asks for commit access, then there is no choice but to consider the proposal and explicitly accept or reject him. If the latter, then it should be done as politely as possible, with a clear explanation: "We liked your patches, but haven't seen enough of them yet," or "We appreciate all your patches, but they required considerable adjustments before they could be applied, so we don't feel comfortable giving you commit access yet. We hope that this will change over time, though." Remember, what you're saying could come as a blow, depending on the person's level of confidence. Try to see it from their point of view as you write the mail. […] " The goal is not to decide to put other VOTEs on this private list. Only for committer voting. Thanks -Vincent