How should we make decisions as a group?

[kd7uiy]

There are a number of times where we have needed to make decisions, that aren't always clear just from the replies on the comment thread. The best example I see of this is #1034, but there are others as well. How should we make these decisions?

[Tranberry]

My two cents:

Number one is to not be to fast in deciding things, an issues that is important should be up for discussion either until Quill makes a decision or most people who work with this relative the the issue have said their cause. (closing an issue that is 'vital' in less than say 10h is a bit fast).

And when a decision is reached we should be open for changes.

I'm not saying that we must wait for Quill, but imo he is the lead dev.

---

Adding to that, the discord chat is good for testing your opinion eg the more people who are on discord the faster we can come to a consensus. But don't forget to post any conclusions to github, in the wiki or anywhere that is relevant.

[kd7uiy]

First of all, I don't think that @quill18 can really manage everything there is to do with this project, or even the major issues. The highest level issues, sure, he should weigh in on, but that might be a bit much to ask.

I'm working on a rough idea, but I think there should be a few teams that we organize, with a "Steering Committee" leading each of them. This steering committee will be composed of a number of people, most likely either 3 or 5, with one of them being appointed as a leader. We need some method of changing that team if required.

The highest level teams should be pretty large. I would propose the following:

• Game Design- In charge of the back story, general theory of the game, deciding mechanics, etc.
• Program Architecture- Responsible for making decisions about how the code is organized, file types used, coding standards, etc.
• Test Team- Responsible to make sure that all PRs are tested, finding and reporting bugs, etc.
• Art Team- Provides guidelines on all artwork, sound, UI, and other visual components.
• Outreach Team- Responsible for blogs, website, etc.

I suppose each of the teams should have the leader be a part of a larger game council, with Quill remaining as the ultimate project leader. They should have the ability to tag issues in the main site for discussion with their team, which probably means they need to be "Gatekeepers", although the test team would remain the primary team responsible for testing everything.

I would propose some set of bylaws to make this binding. Note that the teams proposed above are really just to provide guidance and ensure that guidance is followed. They should all be opened to suggestions from anyone.

This is a really rough sketch, but I think it would help take the project to the next level.

[longtomjr]

I am thinking of also making "admin" type teams, People that can close issues, and is in charge of labeling issues and making sure that it stays on topic etc. Another proposal is that we START USING THE WIKI!! :P Anything official should go there. I know you dont get updates when it changes, but I am working on that.

Also, discord is a great way to co-ordinate our efforts and I am currently looking into message logging and referencing via Discord.

[kd7uiy]

@longtomjr In my thoughts, the "Steering Committees" have as one of their biggest responsibilities updating the wiki with the official guidelines.

[abackwood]

One of the great things of PP is that you can dabble in all areas if you so desire, so i dont think we should divide people up in one area. But if it's just a group of admins that make decisions in that one area and the rest can contribute to wherever that sounds fine

[kd7uiy]

Everyone can still contribute where they want, they just have to meet the standards of the group who is in charge to be approved.

[sboigelot]

I would prefer that we stay away from discord for major decision, they can be discussed there first -of course- but don't forget about the minority of us in different timezone. I'm currently sitting at my desk at 1km from the capital of France: "Bruxelles" (of course, hehe) and it is hard for me to follow the discord in real time.

[Tranberry]

For us on discord I would say this procedure is good for discussion on discord: Start Issue > Talk about it on Discord > Post comments to Issue > Add to wiki. *

So in other words: use dicord for every type of discussion major or minor but keep information updated in issues and finally add to wiki. That way people reluctant to talk in ´chat have a chance to keep up to date on things and we have an 'official' place to look for information.

* This should obviously not be done in a day.

[Sommerbo]

I think the most important thing is not to get too attached to ideas or code because we might have to "murder out babies". As long as everybody understands that their contribution might be axed for something better I think we are in a good position. And I would hope that Quill can provide us with some direction, currently we don't really have any direction and that leads to disparate ideas and code being produced with little or no regard for its value to the project. And finally I would like to see the mod system for sprites up and running asap since that would simplify the graphics workflow since each artist can maintain their own graphics as an equal partner and the "core" graphics can be chosen down the line. And it gives the best chance for developing a coherent graphic style.

[kd7uiy]

@Sommerbo I agree that we lack direction. While Quill no doubt could provide great direction, I don't think we can count on him to do so.

[Tranberry]

We should not be afraid of ping'ing people to issues and PRs, @vogonistic do you have any thoughts on this?

[kd7uiy]

Pinging people isn't a problem at all. The problem is, who should be pinged for a given subject?

[sboigelot]

@kd7uiy we can use the old "who is working on what page" https://github.com/TeamPorcupine/ProjectPorcupine/wiki/Roadmap

[vogonistic]

I like the idea in general, but I don't think it needs to be super formal. If a group of people step up and say that they want to be in charge of pathfinding as an example, I'm all for it until they abuse it. We do need to know who is considered in and how they bless the PRs.

We are already sort of trying this out with the art critic group.

We should definitely put it on the wiki and in the contribute file. The groups would also be responsible for guidance within their area.

[Tranberry]

My take on the Art Critic group is that people who want to talk about art gets that 'role', (I'm assuming we are talking about this group on discord). In my mind it's not any kind of ruling body, just people trying to find a consensus and help each other with feedback.

Maybe add a path-finding group and so on for other areas as well?

[vogonistic]

Helping to find concensus is the same as making decisions to me. I like that it's an inclusive group and that you guys can figure things out. It solves the problem without needing to resort to a heavier structure.

[kd7uiy]

Okay, I think I'm getting the following:

1. Setting up teams, or steering committees, is desired.
2. A person, or small group of people, leading the committee is okay, so long as they don't dictate every decision. Their role should be in asking the questions, collecting consensus, and updating the wiki, and a lesser extent determining if something meets those guidelines.
3. A rigid structure isn't desired. More than we have now seems encouraged.
4. The 4 proposed teams (Art, Software Architecture, Game Design, and Test teams) seem to be a good start, with smaller more transitory teams periodically being formed as well.

[sboigelot]

Related to

1126 #1034 and many other before

The issue here, and in the last few coding related ticket is the same.

We all have different experiences in the industry (or personal) of projects that succeeded or fail due to both side of each argument. And this all over the world, working with a huge range of different cultures of coding.

When over-documenting was the best experience of coder A, it was the worst of coder B. When JSON was wonderful for coder X, XML was better for coder Y.

We won't be able to convince each-other on any of theses topics, and this is crippling our industry with long technical meeting and lost time.

At the end, someone will be unhappy. But we should remember that the root cause of this is simple: we all try to do our best.

Should we try to solve issue like these quicker? Let one week to everyone to expose an opinion. Then vote and decide? Should we have a time limit or someone moderating or summarizing the issues?

I'm really curious about your opinions on this subject

[longtomjr]

I like letting the community brew about these for a bit. Polling/voting makes you choose a solution rather than come up with an intuative one.

Yep, people will stille be unhappy, but I dont think we should rush the discussions.

On Mon, 05 Sep 2016, 03:53 Togis notifications@github.com wrote:

Related to

1126 https://github.com/TeamPorcupine/ProjectPorcupine/issues/1126

1034 https://github.com/TeamPorcupine/ProjectPorcupine/issues/1034 and

many other before

The issue here, and in the last few coding related ticket is the same.

We all have different experiences in the industry (or personal) of projects that succeeded or fail due to both side of each argument. And this all over the world, working with a huge range of different cultures of coding.

When over-documenting was the best experience of coder A, it was the worst of coder B. When JSON was wonderful for coder X, XML was better for coder Y.

We won't be able to convince each-other on any of theses topics, and this is crippling our industry with long technical meeting and lost time.

At the end, someone will be unhappy. But we should remember that the root cause of this is simple: we all try to do our best.

Should we try to solve issue like these quicker? Let one week to everyone to expose an opinion. Then vote and decide? Should we have a time limit or someone moderating or summarizing the issues?

I'm really curious about your opinions on this subject

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/TeamPorcupine/ProjectPorcupine/issues/1058#issuecomment-244643285, or mute the thread https://github.com/notifications/unsubscribe-auth/ADcrFOnO1Z-r0TgUuaGVfggdVy340WfTks5qm3YUgaJpZM4JxgRg .

[bjubes]

I like the approach where we discuss for a while. then when we hit a time based mark like a week or a critical mass of participants, we hold a vote of some sort. Quill has veto power but other than that its the best for letting the community decide. Otherwise we decide on nothing and we either bicker the same points forever or the topic dies with no resolution ever taking place. for fairness sake the vote would also be held over a long period of time, say 5 days, or until no one votes for a period of time, say 18 hours.

[Tranberry]

As long as it is an open vote I'm for that. I do think that the people who have to abide by the decision should have more say in the matter. I'm basically saying avoid strawpoll and similar services and do it like the XML switch issue.

[sboigelot]

@Tranberry

As long as it is an open vote I'm for that. I do think that the people who have to abide by the decision should have more say in the matter. I'm basically saying avoid strawpoll and similar services and do it like the XML switch issue.

this is confusing me as we are using stawpoll in the XML issue

[Tranberry]

we are?

---

Yes an edit, I did not see. Well I'm against that for said reasons above.

---

I know people are eager to help and don't know how to go about that, a simple thing one might do is just keep active in polls, too me this is like town (here goes bad analogy) A decide how town B should build it's roads. While town A not necessary want to hurt town B, I don't think town B's road building should be decided by town A.

[sboigelot]

@Tranberry that thread is getting long

mbstraus commented 8 hours ago I think a vote is in order... can a straw poll be set up or something?

Dormanil commented 8 hours ago I still love that no one here knows about SKON...

sboigelot commented 8 hours ago • edited Data Format Poll : http://www.strawpoll.me/11156965 Serialization Method Pool: http://www.strawpoll.me/11156971

I hope I didn't forget any important options`

[Tranberry]

Yeah, I'm very much against unvetted polls. Well meaning people will do harm in such votes imo.

[sboigelot]

I'm not sure how to translate "unvetted", even after googling it. Can you elaborate?

Edit: ok I saw your edit above

[Tranberry]

http://www.collinsdictionary.com/dictionary/english/unvetted

People voting on issues that they don't understand.

[sboigelot]

Should we keep this open?

[mikejbrown]

Imagine failing to come to a consensus on an issue about how to come to consensus on contentious issues. :stuck_out_tongue_closed_eyes:

[kd7uiy]

I think we do need to keep this open. Sadly, this is proving to be a very contentious process... I could point to a few particularly contentious issues, but we haven't really resolved those, so...

There are a few ways that have been suggested.

1. Attempt to form a consensus with people viewing the issue.
2. Take some kind of a vote among those who are active participants.
3. Let the person who is doing the work decide (Not really suggested here, but it seems to be the practice)
4. Try to form a group of people around specialized topics, and let that group decide, while taking feedback from the entire community.

Is that a far summary of the ideas proposed thus far?

[Geoffrotism]

I like the consensus idea, but it is really quite hard to do when sometimes it seems like only 4-5 people seem to care about a specific topic.

[mikejbrown]

...and they just keep repeating the exact same arguments over and over again...

[Tranberry]

I'm partial to number 3. And while it might not be great to let any silly idea someone who can code into the project that's something people have to deal with.

[sboigelot]

Before finding solution let's define the issue:

Currently we have N teams, with people belonging to multiple teams at the same time

GW: doing the testing, code review, issue admin, and merge Game Design: discussing a lot about the gameplay and story of the game, making good progress and mostly having no debate issue Technical topics; were everyone has great conflicting ideas but we manage to find consensus after 100 post (like every developer team) Art: they mostly do stuff on discord and it seems to work

The question is: do we have an issue?

[kd7uiy]

@sboigelot Sadly, I think we do, as is evident by #1034

@Tranberry I think I like the idea of the people who will be dealing with the problem deciding amongst themselves. The trick is, how do we set that up...

[Tranberry]

I don't really see any option exuding another. It would be great if multiple who are interested in doing similar things could talk with each other before jumping on it.

But I'm kind of with @sboigelot even if this is a valid discussion it's somewhat a discussion that will continue into infinity and rarely lead anywhere, even if I find it interesting to talk about it.

[sboigelot]

For #1034 I think everyone is just waiting for a PR about it, as long as no-one propose code, nothing will change. The KSON team will probably do that in a few... weeks maybe? The decision is: wait and see

[mikejbrown]

When an issue comes to a vote that is likely to be contentious or have a lot of options, I recommend using a service like the Condorcet Internet Voting Service. From the site (emphasis mine):

---

CIVS is a free Internet voting service that makes it easy to conduct polls. Each voter ranks a set of possible choices. Individual voter rankings are combined into an anonymous overall ranking of the choices. CIVS has been used for thousands of polls and elections, deciding, for example:

Officers of organizations
Meeting times
Members of committees
Project and domain names
Award recipients
Restaurants to eat at
Movies to watch
Party menus
Book club selections
Favorite music
Gifts
Logos
Project directions
Invited speakers
Organization bylaws

_How it works: Anyone may create a new CIVS poll, but only authorized voters will know about it. Voters and the poll supervisor must have e-mail and web access. When a poll is created, voters are e-mailed with a URL where they can vote. Public polls may be created that do not require voters to have e-mail addresses; in this case, one vote is allowed per IP address._

_Why rank choices? With CIVS, voters rank their choices rather than just picking their one favorite choice. Ranked-choice voting gives more accurate results because it collects more information from voters. It also helps avoid vote splitting and spoilers._

Ranked-choice voting is used in real elections. For example, Australia uses Single Transferable Vote (STV, also known as IRV). However, the Condorcet methods supported by CIVS are better than STV at identifying consensus candidates. STV can elect a candidate even though a majority of voters would prefer someone else, and it has in real elections. Unlike most other Condorcet systems, CIVS also has a proportional representation mode.

A highly secure version of CIVS called Civitas is under development. Civitas uses much more sophisticated cryptographic protocols to provide strong anonymity, universal verifiability, and coercion resistance.

[Tranberry]

one flaw is that you either need everyone's e-mail or risk vote manipulation.

[mikejbrown]

@Tranberry We have emails for all contributors to the repo.

$ git log --pretty="%ae" | sort | uniq
[ 109 lines of email addresses ]

This misses anyone who only contributes to the wiki or issues/chat, but maybe we can live with that or handle it manually...

[Tranberry]

it would be sweet if you could 'login' with github.

[mikejbrown]

@Tranberry It would be, but I honestly have no idea if that's possible... There is a github repo with the CIVS software if anyone wants to take up running our own server for it. Could also try raising an issue on there.

[mikejbrown]

I opened an issue on CIVS https://github.com/andrewcmyers/civs/issues/11 EDIT: Now have a response from the maintainer of CIVS:

Currently there is zero integration between CIVS and Github. I like the idea of making it easier to create polls for Github project members. And other kinds of online social communities. But it makes sense to start with Github. I'm not sure how difficult this would be, though -- I don't know enough about the APIs Github exposes.

So yeah...

@kd7uiy @longtomjr You've done Github API work, right? Any thoughts here?

[sboigelot]

We should have a few rules:

1. Not changing the content (text) of an option in the vote in the middle of the voting period.
2. If multiple options are on the same level after the voting period, we can re-vote for them, but without any modification to the original options as this would invalidate the elimination of the previous round

Looking at you #1434 (no bad feeling here, I know this is done in good will and probably lost in discord)

[Tranberry]

Not changing a vote in the middle of the voting period.

Can you expand on why this is important, I'm not against it I'm just a but unclear on why it would be bad.

[sboigelot]

@Tranberry Because people that voted before based their decision on the content of the option.

let's take for instance a simple vote

At 3:00 am we post this:

Vote 1 for Using the color blue Vote 2 for Using the color yellow

Between 3:00 am and 7:00 am 12 person vote: 8 for 1, 4 for 2

at 7:02 am the content of vote 1 is changed to

Vote 1 for Using the color blue and banning forever the color yellow

The 8 person that voted previously for 1 didn't specifically agree on the modification. But at the end of the voting period, it will look like it

[mikejbrown]

Ahhh... you mean changing the subject of the vote. Not your choice of yea or nay. All good then.

[sboigelot]

@mikejbrown I updated the original text

[Tranberry]

I thought you meant the person voting blue but changed his/her mind and would now like yellow.

[sboigelot]

@Tranberry no that's fine :)