Code of Conduct #10
Code of Conduct #10
Conversation
|
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! |
|
I think we should adapt the reporting to have our own reporting body. |
|
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 ***@***.***> 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 <#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:
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. |
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 would be the benefit of that over direct to the committee? |
|
what is the benefit of having our own committee? I see the following benefits of using NumFOCUS a. they're a neutral 3rd party |
|
Let's delegate some people to do find out some info on this. Things I think we need to know:
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 ***@***.***> 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 <#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 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 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 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.
I think we're talking about two things here. Who receives the complaint Who assesses the complaint and makes recommendations 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:
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.
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?
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:
and
|
|
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 |
NumFOCUS follows procedures, but occasionally asks Stan folks for context. There is no Stan procedure.
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. |
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 ***@***.***> 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 <#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 ***@***.***> 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 <#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: 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 ***@***.***> 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
<#10?email_source=notifications&email_token=ADRICBQHAIJNDV5OZ4WYWP3QPBQTZA5CNFSM4JATALJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBQB3II#issuecomment-543169953>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADRICBRXLNDMW2SOL6O6LG3QPBQTZANCNFSM4JATALJA>
.
|
|
One more thing @dpsimpson:
It took me a while to parse, but do I understand correctly your experience was very negative? Or that you didn't have a lot of experience with them, but none of it was above average? |
|
I was not blown away by their handling of complex situations. Hell. I
wasn’t blown away by their handling of anything. It is possible that
something has turned around in the last 3 months but I doubt it.
I had a lot of experience. And I would not voluntarily step outside their
core expertise.
…On Thu, Oct 17, 2019 at 09:25 Martin Modrák ***@***.***> wrote:
One more thing @dpsimpson <https://github.com/dpsimpson>:
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.
It took me a while to parse, but do I understand correctly your experience
was very negative? Or that you didn't have a lot of experience?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#10?email_source=notifications&email_token=ADRICBVISB2IBGAXKSLXNTTQPBRUNA5CNFSM4JATALJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBQCX4A#issuecomment-543173616>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADRICBS3TYG3MHUWFZVXLQDQPBRUNANCNFSM4JATALJA>
.
|
Yeah, that makes sense, I think I'm just particularly unimaginative in thinking of ways in which our community is different from all those other communities, but apparently they all agreed they needed it to be tailor-made so maybe that's just a more battle-tested approach?
100% agreed. as you mentioned in the other thread maybe we can just submit the abstracts to the SGB :) I'm also happy to just drop the vanilla NumFOCUS idea - as you note I think we've identified pretty well where we differ and feeling heard is enough for me, haha. Not sure if @mitzimorris (and @SteveBronder ?) are still in favor of vanilla NumFOCUS CoC. |
|
Let me also emphasize that we can and will have disputes that do not involve the code of conduct. Dispute resolution is a general issue within the community, quite separate from any code of conduct issues.
… On Oct 17, 2019, at 9:19 AM, dpsimpson ***@***.*** ***@***.***>> wrote:
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 ***@***.*** ***@***.***>>
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 <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 <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
> <#10?email_source=notifications&email_token=ADRICBQHAIJNDV5OZ4WYWP3QPBQTZA5CNFSM4JATALJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBQB3II#issuecomment-543169953 <#10?email_source=notifications&email_token=ADRICBQHAIJNDV5OZ4WYWP3QPBQTZA5CNFSM4JATALJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBQB3II#issuecomment-543169953>>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ADRICBRXLNDMW2SOL6O6LG3QPBQTZANCNFSM4JATALJA <https://github.com/notifications/unsubscribe-auth/ADRICBRXLNDMW2SOL6O6LG3QPBQTZANCNFSM4JATALJA>>
> .
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#10?email_source=notifications&email_token=AAZYCUKPZBLILT7OOP3Y4GLQPBQ7PA5CNFSM4JATALJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBQCE4Q#issuecomment-543171186>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZYCULSLZL6UXLEPPIYCD3QPBQ7PANCNFSM4JATALJA>.
|
|
I totally agree Andrew! After all, Sean and I disagreed on this but came to a way forward that (at least to me) didn't violate any CoC I can imagine. :) Perhaps a Stan specific CoC should discuss the difference between respectful conflict and coc violating conflict. |
|
@betanalpha <https://github.com/betanalpha> could you elaborate on the procedure of proposing this the the SGB?
With the election coming within the next few weeks the SGB is focusing
on the transition and is somewhat reticent to try to set any policy for the
governance, so even if something was proposed I don’t think anything
would be done in the short time before the transition, leaving it up to the
next governance.
One of the challenges of creating new governance structures with a
community this large is that there are many people who want to voice
opinions and it is very hard to get consensus. Voting becomes
inevitable, but then who gets to vote? Does the SGB simply approve
a CoC or does it have to be ratified by the electorate? If the former
then how does the community buy in without having a voice? How
does the electorate or the community at large accept the CoC? Big
issues like this reveal many of the weaknesses in our current governance.
As I mentioned before we have tried to employ a CoC multiple times
already, and in the span of those failures the community has only
become larger and more varied and invested in their opinions.
I appreciate the sentiment of wanting to working something bespoke
out to unify the community. In addition to the challenge of consensus
when the community has grown so quickly we also have to
acknowledge that these issues are delicate and often it is challenging
to determine what will actually be effective before a CoC is exercised.
One of the benefits of using an established CoC such as the NumFOCUS
CoC in my opinion is not that it is easy or quick but rather that it has been
vetted by lawyers and informed and improved based on experience
from previous complaints. As easy as it is to dismiss existing policies
out of hand I think it would be a waste to not take advantage of the work
that has already been done.
As Martin noted, however, I do think that many people were in favor of
the bulk of the NumFOCUS CoC with the difference of opinion limited
to the reporting structure. One possible step would be to get buy in for
the former while developing the reporting structure.
Again I appreciate and empathize with Lauren’s concern for doing lots
of work only to be told at the end that it was the wrong direction without
explanation. It has happened to me _many_ times on this project and
I don’t think we’re currently equipped to deal with it any better. This
issue is detailed enough that it’s hard to compartmentalize well and
enable incremental progress. Sorry if this ended up sounding dour,
I was trying to respond to multiple points in the past few emails and
wrote myself into a corner with no obvious way forward.
|
|
I think we have a way forward now. Sean no longer wishes to bring the "use the numFocus CoC exact" to the SGB. Unless anyone else has alternative approaches I will write an proposal CoC that reflects as many of the comments that have been made as possible. I will also write a short summary of the relative weak points. I will put both on a fork of Steve's repo and announce on Discourse, here, Andrew's blog and my personal Twitter (i.e., all of the professional mediums I have access to). It will be open for comment for anyone who considers themselves one of the community or who would like to be in the future. Comments can also be made to me privately, because it is sensitive. My only restriction on comments is that they must be specific ("I dislike this bit because of that"). Proposed solutions welcome ("it would be better if we included this"). After a few weeks of consultation I will ratify as many of the comments as possible and propose it to the (new) SGB. For what it's worth, I never intended to change the NumFOCUS CoC that much anyway. I wanted to add reporting practices that included people like Martin, examples of the CoC for each format of community and something to help differentiate between conflict and violations. |
|
My previous comment about wanting to use NumFocus is mostly that
eod, I mostly want to make sure the CoC happens But @lauken13 if you are def able to put in the time to make our own CoC in the next few weeks then I'm cool and good with that approach! Also able to help out if you need a hand!
I think the Request For Comments (RFC) process here does help alleviate some of that if it's posted and then iterated on publicly (EX, this PR. Lots of good discussion, I personally made little effort!). Lauren posting this to multiple venues should help make sure parties that need to be involved will know about the process. *Easy to setup but as Dan mentioned probably not the best thing for us |
|
I just wanted to add that I after some thoughts, reading comments here and other discussions, I completely support @lauken13 's proposal to work through the CoC and build our own. Thanks to everybody for your insights that helped me better understand what's going on and change my mind. |
|
Several questions
Here are some situations: A. Someone new joins the conversation on Discourse. They post ideas and make suggestions about statistical methods, software fixes, new algorithms, etc. They feel that they have been disrespected or worse, so they file a complaint against one or more of the people that they engaged with:
B. same conversation as A, but this time in public - at a meetup or StanCon, same 3 scenarios. C. same scenario as A or B, but conversation moves offline / in private and becomes a personal conversation and now the complaint is one of harassment. D. conflicts among developers about software features, algorithms, development and methodology.
E. interpersonal conflicts among stan-dev people working together on a Stan-related project - arguments about continuing engagement with the Stan project as a whole For each of this (and other) situations we need to think about:
The power dynamics are important, because I think that complaints are more likely to be filed against core members of the community - they have more power. How can we be impartial when judging a complaint against someone we believe to be a valuable colleague? With respect to Inclusion and Diversity - how can we circumvent unconscious biases held by the mostly white and almost entirely male current membership? Biases which, if unchallenged, may result in continued discrimination against non-white, non-male, and otherwise different people? I think that we should use whatever resources we can get from NumFOCUS to make sure that this is properly addressed. |
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.
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
Markdown Rendering Here