Is it necessary to reach a quorum to make a decision?

[arojascastro]

I am wondering when and how should we take a decision. I mean, do we have to reach a quorum in order to make a change or make a decision. We are about 15 members but only a few have time or want to discuss or express their views. I do no think it has to be compulsory to participate but i do think it is desiderable to reach a quorom most of the times.

So if we are 15 people, at least 8 should be enough. I am saying this because when I collaborated with the EADH, the president called for voting every time a big decision had to be made. There was usually a week for voting... of course, some people did not vote because did not have time or interest, which is fine. That would make everything slower but... what are your views on this?

Issue raised originally in #787.

[amsichani]

I think this is a very important issue for our overall workflow. I second the idea of the quorum (of 8 people at least as for now) as a democratic minimum, unless a major concern is raised against it on time. For making our life easier and because all of us have different ways to check/assess PH issues, I d propose to create a new label named "quorum" so we know that those ones are the top priorities for the well-functioning of the team and we should put them first on our (daily) PH issue-checking list.

[ianmilligan1]

Quorum sounds like a good idea.

Moving towards formal votes on everything, though, is a fairly big departure from the slow-moving consensus model we've adopted, where ideas move up through the ticket system and are more-or-less adopted by consensus or tabled for further discussion at the weekly calls. That said, my schedule is making it tough to get on these calls.

Maybe it's unavoidable since the team is so large.

I think at times people don't chime in on discussions not because they don't care, but because perhaps they're conflict adverse. The quorum label is a good one to help fight through the noise of GitHub notifications.

[walshbr]

I'd also just ask - does a quorum need to be reached on skype, by email, or by github? I'd recommend against aiming to use the skype calls to try to reach a quorum. In the last six months or so I think we've only had eight people or more maybe on a single call…we'd never get any votes done, as scheduling is too difficult. Email or GitHub seems fine to me. My own view tends towards lazy consensus for these sorts of things, but if people want to move towards a quorum system that's fine. My own two cents on the math of it though - we're not really 15. Since Amanda is acting as ombudsperson only, she won't be making meetings or taking votes, so that puts us at 14 by my count just now (though I could always be miscounting). And we have two people on sabbatical right now, so that would put us at 12. 8/12 feels like a pretty high threshold to make for any decision. Maybe something more along the lines of "a quorum is made up of half of the currently active editors" would feel more doable. That would put a quorum at 6.

[alsalin]

I'm no github notifications wizard - but we'd want to make sure that everyone sees these posts that require a quorum. I know that folks have their notifications set up differently, but I could totally see people not keeping up to date with an issue not because they don't care, but just because they haven't seen it yet.

[arojascastro]

My view is that reaching a quorum is the ideal situation. I like the concept of lazy consensus but sometimes as @alsalin said people cannot participate because do not see the notification or because some active editors are very fast and the topic has already moved. In those scenarios lazy consensus is not ok, I do not like leaving people behind specially when we are making big decisions that are concerning everybody. However, it can be frustrating for some people to see that their contributions are ignored or that nothing is happening.

[walshbr]

Totally @arojascastro. And given @alsalin's good thought about github notifications maybe it makes sense to think of the google group as the space for quorums?

[drjwbaker]

To add, we make lots of decisions everyday. We editors should have the common sense to realise when a decision merits a quorum, and it is tricky/impossible to define that. We have to trust each other or working together won't work. We need to be mindful of not creating too much work for ourselves or compromising our agility. And we have a little checks and balances in the GitHub pull request review system, so that if something slips through the common sense net that shouldn't have, it can/should get bounced back to quorum. So I vote :) for more openness around the fact we do already use quorum and precision around the mechanisms for agreeing it (we do, for example, tend to use our monthly calls for it) but not for requiring quorum on everything or over-specifying the circumstances that require quorum.

(and to add, thanks for raising @arojascastro!)

[mdlincoln]

Discussed in 2018-04-23 meeting:

@arojascastro is right, lazy consensus does not work if we move too fast to ensure that all team members have the chance to weigh in. However, I'd echo concerns expressed here, and in the call, that instituting a formal voting system may exacerbate fractious feelings within the editorial team - e.g. if one team member feels especially passionate about a decision, can they simply be overruled by a majority? When in fact the core problem is that we want to make sure there is enough time given over to discussion of policy questions so that everyone has an opportunity to see the issue and provide feedback if they wish to.

What we'd propose is that any issues that pertain to policy changes should be labeled with the policy tag. If there is some actionable item (like adding new text to the editorial guidelines for example) then a formal deadline is announced in the ticket (and on the email group) preferably after the next editorial call, so that all team members know where they can register their opinion.

Any thoughts on this?

[arojascastro]

It sounds very reasonable and helpful and I love labels and deadlines -- honestly, they give me a safety feeling.

[drjwbaker]

I presume a perfectly valid decision on a policy matter with a deadline is to defer the decision. In which case, can I suggest we always attempt to set a new deadline.

[mdlincoln]

I have tried to write up some guide to our lazy consensus: https://github.com/programminghistorian/jekyll/wiki/Programming-Historian-Governance

This is very much a draft, so comments are welcomed.

[acrymble]

very happy with what you wrote.

[drjwbaker]

Ditto. Thanks for taking this Matt.

[arojascastro]

Very accurate! Thank you

[walshbr]

Looks great!

[amsichani]

Looks great to me! Thanks @mdlincoln !

[mdlincoln]

After the 2018-05-31 call I'm closing out this issue. For any other specific ?s that come up with this, please open up a new issue.