design-docs
design-docs copied to clipboard
stan-dev
Code of Conduct
This is a first draft for Stan's code of Conduct, it's NumFOCUS's CoC with a find and replace for NumFOCUS for Stan.
There's a few outstanding points I've marked as TODO, and also the two points Lauren plans to add based on Dan's Comments.
- Like with NumFOCUS, should there be a Stan privacy policy which they list as well?
- Should we use the same reporting form that NumFOCUS uses?
Also, Mitzy pointed this out earlier and I didn't catch it, if NumFOCUS was cool with Stan using their CoC services and reporting, could we pretty much do away with having our own and use all of their things? i.e. we could just say in places, "Stan follows the NumFocus CoC [link]" Then we don't have to do anything and we get a pretty nice process. I think we all agree (mostly) that the NumFOCUS CoC covers 99% of what we want. Maybe we could literally have our CoC page say
Stan and all related projects follow the NumFOCUS Code of Conduct[link], with these additional adduendums
I'm a big fan of @mitzimorris 's idea as I understand it to not innovate here and defer to NumFOCUS CoC and reporting wholesale as much as possible - we pay them money for stuff like this (I think).
I'm a big fan of @mitzimorris 's idea as I understand it to not innovate here and defer to NumFOCUS CoC and reporting wholesale as much as possible - we pay them money for stuff like this (I think).
Yeah I agree, can we check with them if that's cool? Then all should be good!
Establishing a reporting body has always been tricky because they need to have the authority to begin an investigation without all members of the governing body in case of conflicts of interest. Perhaps it would be easiest to start with something simple — such as a committee of three individuals who can all receive reports independently, only one of whom may be on the board.
On Oct 14, 2019, at 3:50 PM, Lauren Kennedy [email protected] wrote:
I think we should adapt the reporting to have our own reporting body.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/stan-dev/design-docs/pull/10?email_source=notifications&email_token=AALU3FRK26TAYEEN3JK3LPLQOTESDA5CNFSM4JATALJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBGIAGQ#issuecomment-541884442, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALU3FQ4MLAB7CFCKZ2OYZTQOTESDANCNFSM4JATALJA.
Five people to allow some to step aside for COIs and still have enough to support each other?
Procedure would be:
- Receive report either directly OR to a group email (person can specify they don't want certain people involved).
- Contact the rest of the committee
- Anyone on the committee with a financial or personal COI steps aside. Committee members can ask for someone to stand aside if they don't voluntarily.
- Remaining people contact the person who made a complaint and gather any additional information.
- Make decision.
- Discuss outcome with person who made complaint to ensure they are comfortable with the outcome. Outcomes as per numFocus list.
- Make recommendations to the SGB who are responsible for enacting.
Is it necessary for someone from the committee to be on the board? Definitely agree that it should be at most 1 but I don't think it needs to be any.
Receive report either directly OR to a group email (person can specify they don't want certain people involved).
What if we did this via numfocus? i.e. NumFocus receives a report and reports that to a group of N Stan people excluding any that might be in the report?
what is the benefit of having our own committee?
I see the following benefits of using NumFOCUS
a. they're a neutral 3rd party b. they have resources dedicated to this sort of stuff c. removes burden on Stan community of choosing, training, and otherwise managing (yet another) committee.
Let's delegate some people to do find out some info on this. Things I think we need to know:
- Do other NumFOCUS entities use NumFOCUS for this? Why/why not? e.g., Julia have their own (https://julialang.org/community/stewards/)
- Does NumFOCUS actually agree to act in this capacity? Will they act according to their CoC?
Anyone have anything else they'd like to know? Does anyone want to volunteer to get this info? Maybe @seantalts or another member of the SGB can get the info from NumFOCUS?
Great questions - I sent an email to Leah and Gina at NumFOCUS but both are out of office for a while according to their autoreplies. Maybe @breckbaldwin knows someone else there we could ask about this?
I can’t really be very specific here, but we had some interaction of this nature with the NumFOCUS team when I was on the SGB and I wouldn’t recommend passing responsibility for CoC violations to them.
I do, however, think it should be done by a team that does not contain any developers.
To clarify an important point — NumFOCUS takes the position of now wanting to make decisions about CoC violations within individual projects, instead they will perform initial investigations and then delegate to a project’s governing body. In other words NumFOCUS might serve be a viable reporting mechanism but any more than that would be the responsibility of the project.
This does raise an interesting point about how sophisticated the reporting process will be.
I personally was thinking about a reporting body that was responsible only for receiving complaints and then determining who amongst the governing body is appropriate to be included in the complaint discussion. In other words they are just a layer to ensure that people feel safe making complaints, with the governing body responsible for the investigation and outcome. This is the simplest approach, and hence easiest to implement.
You suggest that the CoC committee be more than just a reporting layer but rather perform an initial investigation and form a render a recommended outcome to the governing body. This has plenty of advantages, but it does require more structure. Namely, how would the CoC committee be appointed and governed to ensure that all parties involved trust the results?
I don’t have a preference between the two, so long as the latter is carefully through out. At the same time a simpler CoC might be beneficial for quicker adoption, serving as a baseline for future improvements such as an independent CoC committee.
On Oct 14, 2019, at 5:35 PM, Lauren Kennedy [email protected] wrote:
Let's delegate some people to do find out some info on this. Things I think we need to know:
Do other NumFOCUS entities use NumFOCUS for this? Why/why not? e.g., Julia have their own (https://julialang.org/community/stewards/ https://julialang.org/community/stewards/) Does NumFOCUS actually agree to act in this capacity? Will they act according to their CoC? Anyone have anything else they'd like to know? Does anyone want to volunteer to get this info? Maybe @seantalts https://github.com/seantalts or another member of the SGB can get the info from NumFOCUS?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/stan-dev/design-docs/pull/10?email_source=notifications&email_token=AALU3FTTM7NMWOQAFP6V4LLQOTQ2JA5CNFSM4JATALJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBGUQ5Q#issuecomment-541935734, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALU3FSGERG5UOVGHSJEQH3QOTQ2JANCNFSM4JATALJA.
I think that's a really good point Michael and I appreciate you raising it.
My preference is the longer, slower and more deliberate process of working through this on our own. Alex Hayes made an excellent point on Discourse (https://discourse.mc-stan.org/t/code-of-conduct-for-stan/11324/42?) that working through it helped them to formalize what the process would look like and feel like, which I think is an important point.
I believe the CoC (EDI committee?) committee should be separate to the SGB. As for a proposal let me put something forward. I wrote this at 7am this morning so bare that in mind when critiquing.
Selection The CoC committee is selected by election at the same time as the SGB, with one member selected for a longer "two terms of the SGB" to ensure continuity and procedural sharing.
The CoC is formed of three to five individuals, consisting of no more than two developers, no more than two community members of any single field, no more than one person in an existing position of power (e.g. tech leads or SGB member), no more than two people employed by the same workplace (unless in the case of a committee with less than 4 members where no one may share the same employer) and no more than two people of one gender.
Each individual of the CoC is voted on separately with "rejection voting". If more than 1/3 of the voting electorate "reject" an individual then they will not hold the position. If the rejection voting results in a CoC makeup violation, then members will be selected preferentially based on smallest number of votes. Draws will be called with a random number generator.
Failure to select a new CoC committee that conforms to this will result in replacement of as many individuals as possible on the existing committee. Replacement of places will be done first by volunteer and then by random number generator.
Governance and accountability The CoC committee is independent of all other Stan bodies. Conflicts within the CoC will be arbitrated by the SGB. The CoC committee is responsible for open and transparent investigation of all complaints. Reports will be made of each and every investigation. They may be kept private to protect the person who made the complaint, but at a bare minimum an anonymized report of the complaint, investigative procedure and result will be made to all members of the SGB who are not named in the report.
The report must contain details of how the complaint was investigated, any violations to the CoC and the proposed solution. The report will be amended within 6 months on the final resolution and a reflection on the efficacy of the solution.
A summary report of the number of complaints and the outcomes will be made to the community provided the details are sufficiently anonymized (those who made complaints will have the opportunity to view this report before it's release and will have ultimate veto power on any specific detail).
I know there's a temptation to feel time pressure with an upcoming SGB election, but I really don't think that this should come into it. Let's put our best foot forward no matter what else is happening.
I strongly agree with everything that Lauren says.
Regarding the SGB time pressure, maybe one way the SGB could do something within the available time would be to make an ex officio position on the board for the chair of the EDI committee (or whatever it's called)? This is similar to what ISBA did when it made it's equivalent EDI committee and it allows easier flow of information while keeping the EDI committee independent* of the SGB. I'll tag in @seantalts @jgabry and @betanalpha who I think are the 3 members of the SGB who are likely to see this. (Obviously, please ignore if you think it's a rubbish idea!)
- I think keeping these things independent is a good thing. This is not a comment at all on the SGB, but rather an acknowledgement that these two bodies are optimized for different things. For example it makes a lot of sense for the SGB to be "developer heavy", while it makes less sense for an EDI committee to over-represent one group in the community.
I think that's a really good point Michael and I appreciate you raising it.
My preference is the longer, slower and more deliberate process of working through this on our own. Alex Hayes made an excellent point on Discourse (https://discourse.mc-stan.org/t/code-of-conduct-for-stan/11324/42 https://discourse.mc-stan.org/t/code-of-conduct-for-stan/11324/42?) that working through it helped them to formalize what the process would look like and feel like, which I think is an important point.
I definitely appreciate that — certainly these discussions and mental simulations help clarify priorities and necessary structures — but my concerns are two fold.
Firstly the more structure the more potential for contention and the harder something will be to earn ratification however that might be defined. I see how one could argue that under such disagreement we shouldn’t try to push anything through, but that also leaves us exposed without of CoC. I think that having people agree to the CoC to join the community goes a long way towards increasing awareness of the potential issues.
Secondly there is the question of logistics. The more sophisticated the procedure the more care will be required in its implementation. That sophistication in turn requires a maturity and buy-in from the leadership of the community for which we may not yet be equipped. Having a simpler CoC would allow us to start with something that is easier to implement and which might serve as a foundation on which to build a more scalable system.
Again, not at all trying to discourage a more sophisticated process just noting some potential obstacles that will have to be addressed and have had some responsibility in the lack of CoC to this point. An initial CoC need not be the final CoC!
I believe the CoC (EDI committee?) committee should be separate to the SGB. As for a proposal let me put something forward. I wrote this at 7am this morning so bare that in mind when critiquing.
My only concern with EDI is that it implies a scope much larger than the CoC which just gives everything more bureaucratic inertia.
Selection The CoC committee is selected by election at the same time as the SGB, with one member selected for a longer "two terms of the SGB" to ensure continuity and procedural sharing.
The CoC is formed of three to five individuals, consisting of no more than two developers, no more than two community members of any single field, no more than one person in an existing position of power (e.g. tech leads or SGB member), no more than two people employed by the same workplace (unless in the case of a committee with less than 4 members where no one may share the same employer) and no more than two people of one gender
I worry that specifics like this are challenging to enforce given how softly they can be defined. Employer (also general COI for people like myself who consult could be a consideration as well) and existing leadership position (SGB or TWG) are easier.
One pattern that I’ve seen a lot is to not explicit limit membership but rather explicitly state the desired membership in the governance to help inform whomever is deciding on those members. For example something like “The CoC committee should represent the entire Stan community, including but not limited to role, background, race, ethnicity, and gender. Voters are encouraged to take this into consideration when casting their votes”. Again, just an example.
Each individual of the CoC is voted on separately with "rejection voting". If more than 1/3 of the voting electorate "reject" an individual then they will not hold the position. If the rejection voting results in a CoC makeup violation, then members will be selected preferentially based on smallest number of votes. Draws will be called with a random number generator.
How are candidates nominated? Who is eligible for nominations and nominating? Part of this is complicated by the current uncertainty in the governing body structure, but I do think that it’s easier to start with a committee appointed by the governing body after which point it attains some independence, just because it avoids these logistical challenges.
Failure to select a new CoC committee that conforms to this will result in replacement of as many individuals as possible on the existing committee. Replacement of places will be done first by volunteer and then by random number generator.
Governance and accountability The CoC committee is independent of all other Stan bodies. Conflicts within the CoC will be arbitrated by the SGB. The CoC committee is responsible for open and transparent investigation of all complaints. Reports will be made of each and every investigation. They may be kept private to protect the person who made the complaint, but at a bare minimum an anonymized report of the complaint, investigative procedure and result will be made to all members of the SGB who are not named in the report.
The report must contain details of how the complaint was investigated, any violations to the CoC and the proposed solution. The report will be amended within 6 months on the final resolution and a reflection on the efficacy of the solution.
Who handles the appeals allowed in the NumFOCUS CoC?
I know there's a temptation to feel time pressure with an upcoming SGB election, but I really don't think that this should come into it. Let's put our best foot forward no matter what else is happening.
Totally agree!
Gina sent me a response that essentially says that we can offload to NumFOCUS for this; I've asked permission to post the exact email and will do so if she agrees. She also said it would be good if there are folks in the Stan community designated that NumFOCUS can talk to when an event arises to get context. So this would mean we can designate some group of people as contacts for NumFOCUS but adopt the CoC and its reporting structure wholesale. I think this is a huge win.
I read Alex's comment as saying that it was super hard and arduous to get right and that if you're going to do it yourself, you have to invest seriously. Which I obviously took to support my pre-existing beliefs (lol) that, if we are already paying for these services from NumFOCUS, we ought to take advantage of them because 1) it's hard to get right, 2) it's expensive, and 3) independence is worth a lot. I basically think the expected value of using NumFOCUS is much higher to us than the expected value of trying to engineer and staff our own system indefinitely. However, Gina also sent me this link in case we want to go it alone: https://discover-cookbook.numfocus.org/07_code_of_conduct/
Re: next SGB - we are trying to set up a super barebones election ASAP with very little structure imposed on the next SGB. This is a little scary but elections coupled with candidate statements should give them the legitimacy they need to do that and much more, we hope. It's already being drafted up.
Alex's comment (relevant bit copy and pasted below) highlights that the things they struggled with the most were exactly what Michael said NumFOCUS won't do for us. They receive the complaint and then forward to the SGB.
Who makes CoC enforcement decisions? Is that a consensus process or does one person take the lead? What are the most likely CoC violations? What are the consequences for these violations? How I am going to tell someone who I might know and be friends with that their behavior is unacceptable?
I think we're talking about two things here.
Who receives the complaint Options: NumFOCUS SGB CoC committee
Who assesses the complaint and makes recommendations Options: SGB CoC committee
I also think independence is worth a lot, that's why I'm suggesting that we create an independent and balanced committee of Stan folks to act in this capacity (and like Dan, this is nothing against the SGB current or future.). Comments to Michael's specific concerns below:
I worry that specifics like this are challenging to enforce given how softly they can be defined.
Why not have both your statement and actual restrictions? Can you provide a concrete example of where the restrictions I have suggested would be confusing to implement, I thought they were pretty straight forward but perhaps I'm missing something. The only one that's a little fuzzy would be "more than two of any field". If you think that is too fuzzy compared to the other restrictions it could be removed and added to the suggestions instead.
How are candidates nominated? Who is eligible for nominations and nominating?
Everyone can nominate themselves or others, we put out a call on Discourse, Andrew's blog and Twitter. Nominees have to accept. Each nominee provides a paragraph intro covering background, current position, interest in this role and any experience. Nominees star whether they would consider being in the "two SGB length" role and we take a lottery for that position of those voted on.
This is the perfect time because there's already a vote happening. What's adding a couple extra questions to the ballet paper?
Who handles the appeals allowed in the NumFOCUS CoC?
Appeals can be made to NumFOCUS or the SGB. NumFOCUS will direct back to the SGB who will follow the same procedure and reporting standards as the CoC committee.
NumFOCUS doesn't have to respond to complaints that way; they can actually take over receiving, investigating, and recommending actions on complaints (ideally with consulting from some designated Stan folks).
Here's the full reply from Gina:
Couple thoughts:
- I've proposed an unconference session at the Summit on Code of Conduct enforcement; would be great to have Stan participate in that
- It's fine to fully adopt the NumFOCUS CoC and reporting structure, although in an ideal world there would also be designated CoC responders from the project itself that NumFOCUS can confer with on reports.
Also FWIW, we've heard feedback that some people view NumFOCUS as sort of external to/distant from the project (i.e. if they're part of the Stan community, they may not be as familiar with NumFOCUS and thus would be looking to report to someone within Stan rather than an "external" body), so a project-affiliated reporting/response committee is better than solely the NumFOCUS one in that respect.
and
And just a clarifying point that the aspect of NF potentially being perceived as distant from the project isn’t specific to Stan—that’s more of a general point about project communities and their familiarity with the organization.
Okay it seems like we have two proposals. @seantalts perhaps you could write out how you think the NumFocus + designated Stan folks process would work in terms of procedure. A couple of things to think about - how would the Stan folks be selected? What procedure do they follow? Who makes the final decision? What if Stan folks and nf folks disagree?
Then we present both to the new SGB to vote upon. When does the vote happen?
fyi I've added everyone in the convo as collaborators on my fork if you want to make changes or another branch w/ proposal
A couple of things to think about - how would the Stan folks be selected? What procedure do they follow?
NumFOCUS follows procedures, but occasionally asks Stan folks for context. There is no Stan procedure.
Who makes the final decision? What if Stan folks and nf folks disagree?
NumFOCUS always makes the final decision.
I can get to this next week - basically propose https://numfocus.org/code-of-conduct possibly with "NumFOCUS" swapped out for "Stan" in some places. Seems like figuring out which people on Stan should serve as either a committee or a point of contact is a serious sticking point, so I'd be fine with not doing that and letting NumFOCUS choose who they'd like to contact.
Seems like figuring out which people on Stan should serve as either a committee or a point of contact is a serious sticking point
Not sure where you’re getting this from. Michael seems to think it’s hard for some reason but that’s all as far as I can see in this thread.
I don’t need any fingers to count the number of times I was blown away by numfocus’ handling of complex situations during my time doing stuff with them. Not sure why we would outsource this to them. Not sure why we would outsource this at all without looking properly into Lauren’s proposal properly.
I think it makes sense to consider Numfocus as a resource. I also agree with Dan that Numfocus is just a resource, and that it does not make sense for the Stan org to outsource decision making to them. I also agree with Lauren that it would be good to have a separate committee for this process. It's awkward handling these issues through the Stan Governing Body, and it makes sense to involve more people in the Stan community by having this separate committee. Andrew
On Oct 15, 2019, at 10:39 PM, dpsimpson [email protected] wrote:
Seems like figuring out which people on Stan should serve as either a committee or a point of contact is a serious sticking point
Not sure where you’re getting this from. Michael seems to think it’s hard for some reason but that’s all as far as I can see in this thread.
I don’t need any fingers to count the number of times I was blown away by numfocus’ handling of complex situations during my time doing stuff with them. Not sure why we would outsource this to them. Not sure why we would outsource this at all without looking properly into Lauren’s proposal properly.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/stan-dev/design-docs/pull/10?email_source=notifications&email_token=AAZYCUOACTOKBBKBLZVXGTDQOZ5H5A5CNFSM4JATALJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBK2SHA#issuecomment-542484764, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZYCULFB7FSQV247W3OZDDQOZ5H5ANCNFSM4JATALJA.
@seantalts I realized I didn't reply to your point properly, my apologies. What I heard Alex saying was that they found the process of creating a code of conduct really valuable. I understand that you heard a lot of work. Looking at it, I think both are true. It is a lot of work, but the work has the potential to be more beneficial than a rarely used punishment system.
@andrewgelman asked me to have a go at trying to work something out. I'm willing to, and I'm willing to put the time and effort into doing it because I do believe that the time spent could result in something that we're proud to have produced as a community. I felt Alex was proud of what they had done and what they had achieved. That isn't to say anything about the NumFocus code of conduct (which I quite like other than the reporting procedure), but rather that there's value in working through this ourselves because it helps to shape us as a community.
What I don't want to is force my opinion onto a broader community that would prefer to go with the simpler option. Nor do I want to spend weeks crafting something that I feel suits us perfectly that then is rejected because the simpler option was always going to be preferred.
Given that, I'm not sure where to go from here. It feels like we are at a stalemate. Half of the commenters would prefer the NumFOCUS adoption method, half the commenters like the independence of my proposal, there's not much middle ground that I can see in between (if anyone has a compromise please shout out). What do you think we can do to resolve this?
In general more sophisticated proposals are riskier; I’m not sure if there’s any way around that. The more structure the more possible points of contention there are and in my experience the harder it can be to get consensus from the relevant stakeholders (especially when there is a “no” or “status quo” option). Indeed we have had difficulty implementing nontrivial governmental structures and getting buy in from the community for those structures.
I understand if you wouldn’t want to take that risk, but personally I think it would be hugely valuable to have a well thought out alternative to having no code of conduct or something like defaulting to NumFOCUS if you were to take on that risk. Even if the simpler version does end up being preferred by the community, having something more sophisticated available would be super useful if/when limitations of that simpler version are encountered in practice.
There may be some middle ground in the form of adopting a simpler code of conduct now as provisional to give us coverage and community buy in as soon as possible while also giving us time to adopt a more thorough, sophisticated version. My only fear there is having to get everyone in the community to accept a code of conduct twice, but maybe I’m just exaggerating that fear.
Anyways, if you do decide to keep working on something I’m happy to help in whatever way I can.
On Oct 16, 2019, at 12:03 AM, Lauren Kennedy [email protected] wrote:
@seantalts https://github.com/seantalts I realized I didn't reply to your point properly, my apologies. What I heard Alex saying was that they found the process of creating a code of conduct really valuable. I understand that you heard a lot of work. Looking at it, I think both are true. It is a lot of work, but the work has the potential to be more beneficial than a rarely used punishment system.
@andrewgelman https://github.com/andrewgelman asked me to have a go at trying to work something out. I'm willing to, and I'm willing to put the time and effort into doing it because I do believe that the time spent could result in something that we're proud to have produced as a community. I felt Alex was proud of what they had done and what they had achieved. That isn't to say anything about the NumFocus code of conduct (which I quite like other than the reporting procedure), but rather that there's value in working through this ourselves because it helps to shape us as a community.
What I don't want to is force my opinion onto a broader community that would prefer to go with the simpler option. Nor do I want to spend weeks crafting something that I feel suits us perfectly that then is rejected because the simpler option was always going to be preferred.
Given that, I'm not sure where to go from here. It feels like we are at a stalemate. Half of the commenters would prefer the NumFOCUS adoption method, half the commenters like the independence of my proposal, there's not much middle ground that I can see in between (if anyone has a compromise please shout out). What do you think we can do to resolve this?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stan-dev/design-docs/pull/10?email_source=notifications&email_token=AALU3FVL5UDMY2JD366CE7LQO2G73A5CNFSM4JATALJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBK65GY#issuecomment-542502555, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALU3FRYIIJOYW6JIQGUFR3QO2G73ANCNFSM4JATALJA.
+1 to everything Michael says (I'm a bit more optimistic about getting this through, but we'll see).
I definitely agree that there's a danger in going for a "half" version for simplicity. I think it's likely that whatever code is adopted is going ot be the code for a while.
Possibly one way to help with buy in is to do a broader consultation phase once the CoC is in full proposal state. And then revise.
I don't think "no" is an option - having a code of conduct is a NumFOCUS requirement that we have been flaunting for a while now. "Run through NumFOCUS" is a possibility, but I don't think it's a neutral one (or to say it differently, I don't think it's an obvious default choice).
One weird question: Is it enough for the new SGB to approve the Code of Conduct? Or does it need to be a referendum?
Yeah, I like the simplicity argument esp. w.r.t. passing stuff and having more points of failure, but I also don't really see the gain of even innovating well in that area vs using something other folks have come up with. Feels a bit like https://xkcd.com/927/
I think it's pretty reasonable to put multiple up to referendum and see what happens, though I'd like to see them annotated with rough dollar amounts of investment required since this stuff isn't free and obviously that money comes from somewhere.
[edit] agreed we need something and that 'no' isn't a real option.
@seantalts I'm confused about your comment of innovating. I can't find a single NumFOCUS entity that has on their webpage "We accept the NumFOCUS CoC in it's entirety and encourage users to report to them" - admittedly I clicked mostly on ones I'd heard of so there's a selection bias.
For example: NumPy (https://numpy.org/devdocs/dev/conduct/code_of_conduct.html) Julia (https://julialang.org/community/stewards/) QuantEcon (couldn't find a coc through google) Cantera (https://github.com/Cantera/cantera/blob/master/CODE_OF_CONDUCT.md) ROpenSci (https://ropensci.org/blog/2019/01/14/conduct/)
Accepting the NumFOCUS code of conduct is a deviation away from the standard model. I can see how you might think that everyone is adopting their own, slightly different code of conducts, and think that they're all analogous to reinventing similar programming languages. To me what they're doing is creating a CoC that reflects their community, and no two communities are the same.
I am reluctant to put multiple CoCs up for referendum. They're often very similar and I think it would be kind of confusing. In addition your voting body is entirely developers, but the CoC covers a lot more people. For example. I would not be able to vote for my own proposal. I would not be able to vote for the standards that govern the community I'm involved in. In my opinion what would be better would be if we could discuss the merits of each proposal without making people go to the weeks worth of work to write a full proposal.
I feel the reason why we are finding it difficult to do that at the moment is because I'm hearing that the merits of the "go with NumFOCUS" proposal is that it is quick, cheap and doesn't cost anyone's time. The merits of my proposal is that it is reflective, time expensive and (I hope) will help to shape and reflect the community's feelings on these matters. What I feel we have is a value difference, and I'm not sure how to reconcile that because it's the worst sort - they're opposites of each other. :)
@betanalpha could you elaborate on the procedure of proposing this the the SGB? If it were treated like a pull request (I propose a rough outline the SGB in principle agrees on. I go do the work of writing and consultation with the community, I create a full CoC that reflects that and submit it to the SGB. SGB then discusses and sends back comments. I reflect on those comments and adapt the COC where needed. I submit back the SGB for final vote). I would be happy to put in the time. What I am afraid of is that I put in a huge amount of work, send it to the SGB which gets discussed in a closed meeting, and then all I get in return is a yes/no.
Thanks everybody for having this discussion, it seems there already was a lot of effort in formulating those ideas. One thing I would like to clarify: if I understand it correctly, the only point that is contentious is reporting. I.e. there is an agreement that the NumFOCUS CoC is good at saying what we strive for, what is desired behavior and what is unacceptable behavior. Is that correct? Because voting on two different CoCs sounds to me a lot more challenging than voting on two different reporting policies (because reporting policies are IMHO less abstract and less dependent on details of wording).
And while I agree with @lauken13 that going through the process is valuable, I have some fear in that regard. There seem to be multiple ongoing conflicts within the community (which I have yet to understand enough to be willing to discuss specifics). I fear that a prolonged CoC discussion could drain energy that could otherwise be redirected to resolving those ongoing conflicts. I fear that the CoC discussion could even become a battleground for some of those conflicts. I would also like to have a good CoC quickly, as I have already encountered a situation where the current "CoC" (https://discourse.mc-stan.org/faq) was IMHO insufficient and had the NumFOCUS one (or similar) been adopted, it would open my options a bit. Nothing of this is critical - the hard parts are always people and relationships, CoC can only help so much. I am therefore not in strong opposition towards the longer process, but I want to note concrete areas where it could cost us something, not only money and time.
I am wary of prioritizing putting out fires with our devs over the broader stan community.
I don’t think the only difference will be the reporting body. It’s hard to say because the process hasn’t started.
On Thu, Oct 17, 2019 at 09:16 Martin Modrák [email protected] wrote:
Thanks everybody for having this discussion, it seems there already was a lot of effort in formulating those ideas. One thing I would like to clarify: if I understand it correctly, the only point that is contentious is reporting. I.e. there is an agreement that the NumFOCUS CoC is good at saying what we strive for, what is desired behavior and what is unacceptable behavior. Is that correct? Because voting on two different CoCs sounds to me a lot more challenging than voting on two different reporting policies (because reporting policies are IMHO less abstract and less dependent on details of wording).
And while I agree with @lauken13 https://github.com/lauken13 that going through the process is valuable, I have some fear in that regard. There seem to be multiple ongoing conflicts within the community (which I have yet to understand enough to be willing to discuss specifics). I fear that a prolonged CoC discussion could drain energy that could otherwise be redirected to resolving those ongoing conflicts. I fear that the CoC discussion could even become a battleground for some of those conflicts. I would also like to have a good CoC quickly, as I have already encountered a situation where the current "CoC" (https://discourse.mc-stan.org/faq) was IMHO insufficient and had the NumFOCUS one (or similar) been adopted, it would open my options a bit. Nothing of this is critical - the hard parts are always people and relationships, CoC can only help so much. I am therefore not in strong opposition towards the longer process, but I want to note concrete areas where it could cost us something, not only money and time.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/stan-dev/design-docs/pull/10?email_source=notifications&email_token=ADRICBQHAIJNDV5OZ4WYWP3QPBQTZA5CNFSM4JATALJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBQB3II#issuecomment-543169953, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADRICBRXLNDMW2SOL6O6LG3QPBQTZANCNFSM4JATALJA .