ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

How to review and discuss new potential committers (Task #100)


Added by Eric Davis at 2011-01-22 01:03 am. Updated at 2011-02-01 10:49 pm.


Status:Open Start date:2011-01-22
Priority:Normal Due date:
Assignee:Eric Davis % Done:

0%

Category:ChiliProject - Organization
Target version:-
Remote issue URL:

Description

As part of the New Committer Setup there is a section to vote and discuss adding new committers. I think this discussion should be only among existing committers so frank feedback can be posted but it feels odd to me having this private. What should we do?


Associated revisions

Revision 57ecf525
Added by Felix Schäfer at 2011-08-21 07:58 pm

Merge pull request #100 from thegcat/feature/517-put_faster_csv_in_the_gemfile

Rip faster_csv out of lib into the Gemfile. #517

History

Updated by Felix Schäfer at 2011-01-30 04:20 pm

I think I like the proposal, though we should define a threshold of votes cast so that you don't end up with someone not being let in because 1 or 2 committers haven't voiced their mind (because of illness/no time at the moment/vacation/whatever).

Regarding the openness of the conversation: I'd vote to keep it open, that way the arguments (if any) will more likely stay non-personal, and I don't expect that much argument as I'd expect people to propose new committers only if they are reasonably sure that they will be accepted. One still has IRC/whatever to have semi-private discussion before making an "official" proposal, so I don't think we need a private channel. That being said, if ever the need arises, we can still create one, but I don't think we need it and we should keep it public for the moment.

Updated by Niels Lindenthal at 2011-01-30 06:54 pm

I vote against the proposed process for two reasons:

  1. Only committers have vote-rights. This excludes the remaining community members.
  2. It should never happen that one person can stop decisions like this. I don't consider this to be open. I propose some kind of 3/4 majority like we have in a parliamentary democracy.
  • Assignee deleted (Eric Davis)

Updated by Muntek Singh at 2011-01-31 12:33 am

I think the proposal is sound, and I have seen this same exact methodology work well in many other projects (subversion for example)

Updated by Eric Davis at 2011-01-31 10:20 pm

Felix Schäfer wrote:

I think I like the proposal, though we should define a threshold of votes cast so that you don't end up with someone not being let in because 1 or 2 committers haven't voiced their mind (because of illness/no time at the moment/vacation/whatever).

I was thinking a delay before voting. I have "After a few days" right now but we might want to make it "After a few days up to 2 weeks". If a committer hasn't voted after two weeks then I'd think they would be sitting out that vote.

Regarding the openness of the conversation: I'd vote to keep it open <snip>

I think that would be best. The only reason I could see it needing to be private is if someone wants to be critical of the new committers work but doesn't want to do so publicly for some reason. Say they work with that person or they have a personal friendship that would be impacted. I think in this case they could talk with me (as project lead) or someone else about it to keep it anonymous.

Niels Lindenthal wrote:

  1. Only committers have vote-rights. This excludes the remaining community members.

Since it is the committers' responsibility to maintain the code it should be up to them to decide who else should be allowed to commit.

  1. It should never happen that one person can stop decisions like this. I don't consider this to be open. I propose some kind of 3/4 majority like we have in a parliamentary democracy.

If one person votes no then a discussion should start about why not ("If there is a single "no", then the committers should discuss any concerns and see about reaching an agreement"). I believe after a discussion there will be an common agreement towards one direction: yes, no, or wait.

  • Assignee set to Eric Davis

Updated by Felix Schäfer at 2011-02-01 10:49 pm

  • Status set to Open

Also available in: Atom PDF