[Bigbang-dev] BigBang project code of conduct

[Sebastian Benthall]

I've made some tickets to sum up some things that have come up in this
discussion:

https://github.com/datactive/bigbang/issues/325
https://github.com/datactive/bigbang/issues/326

I hope you'll forgive me if these seem like pedantic points.

I've spent the past year working for an ethicist among many lawyers, and so
find the nuances here intellectually interesting.

As an aspiration, I would hope that a team of PhD scholars on Internet
Governance, Human Rights, etc. etc. could get their own self-governance
process *precisely* right, and maybe even publish on it one day.

I don't intend for these questions to detract in any way from the *spirit *of
the Code of Conduct, which I expect is absolutely clear to everybody.

I've assigned these tickets to the 0.3 milestone, so we can focus on
getting version 0.2 "Tulip Revolution" out the door as fast as possible.

On Fri, Apr 13, 2018 at 8:27 AM, Sebastian Benthall <sbenthall at gmail.com>
wrote:

> I do like the idea of Nick and Corinne being an ombudsteam.
>
> Taking a close look at the code of conduct, a key thing about it is that
> it is a pledge of contributors and maintainers to participants in the
> project and community.
>
> It would be good if the code of conduct was consistent with the roles
> specified in the Governance document. (This may mean ammending the
> Goverance document, or the Code).
>
> Here's what the current Governance document says about Community and
> Contributors:
>
> "The Project Community consists of all Contributors and Users of the
>> Project. Contributors work on behalf of and are responsible to the larger
>> Project Community and we strive to keep the barrier between Contributors
>> and Users as low as possible."
>
>
> The first thing I want to say is that we don't yet have a Users community.
> It would be great if we had one, and leadership for it.
>
> Another thing is that we do not have a category of "maintainers". Maybe we
> should have one.
>
> A key aspect of consensus based democracy is that the governance mechanism
> only really comes into play when there's a breakdown in consensus and
> things come to a vote. This is a rare event in open source projects because
> a breakdown in consensus can also result in a fork.
>
> Fogel has a good section on why voting rights should sometimes be extended
> to a category of 'Maintainers' which is different from the category of
> 'committers'. The latter is roughly what we've been after with the 'Core
> Developers' category.
>
> https://producingoss.com/en/consensus-democracy.html#electorate
>
> The definition of 'committer' loops back to "maintainer of the software
> code".
>
> The main thing I would want before making a category for Maintainers is a
> better sense of what responsibilities a maintainer of something that's not
> the software code is committing to, and what metrics could be used to
> evaluate their activity.
>
> I hope this question of metrics does not come as a surprise. It is sort of
> the whole point of BigBang to develop a more refined quantitative
> understanding of the relationship between different activities in open
> collaboration.
>
> On Fri, Apr 13, 2018 at 4:51 AM, Niels ten Oever <niels at article19.org>
> wrote:
>
>> Hi all,
>>
>> Perhaps we can have something like an ombudsteam with one core maintainer
>> and one non-core maintainer?
>>
>> Perhaps Nick and Corinne? We could indicate their addresses so that if
>> someone has issues with Nick, they can take it up with Corinne?
>>
>> I agree it is odd that if someone has issues with me, their complaint
>> lands in my mailbox.
>>
>> Happy to discuss.
>>
>> Niels
>>
>>
>> On Apr 12, 2018, at 23:09, Nick Doty <npdoty at ischool.berkeley.edu> wrote:
>>
>>> Thanks for the note, Corinne.
>>>
>>> I think it's an inherent issue in handling code of conduct issues within
>>> a small group. There need to be project maintainers to contact with issues
>>> because project maintainers are the ones who are responsible for managing
>>> participation in the project, but especially with a project with a small
>>> group of maintainers, complaints might be about those maintainers or
>>> someone they're close to. The code of conduct is explicitly intended to
>>> apply to the maintainers as well.
>>>
>>> I would be fine with decreasing membership on the owners/complaints list
>>> so that it isn't all of the most recent developers (four dudes), although I
>>> think having at least 2-3 people is good so that issues don't just get
>>> dropped if someone is offline. I think it would be ideal to have some
>>> diversity of gender on that list, but I'm also hesitant to immediately put
>>> a burden on incoming participants like Corinne.
>>>
>>> I'm open to suggestions. I think we can continue to make changes over
>>> time, including while the code of conduct process is in place.
>>>
>>> Cheers,
>>> Nick
>>>
>>> On Apr 12, 2018, at 8:58 AM, Corinne Cath <corinnecath at gmail.com> wrote:
>>>
>>> Hi both,
>>>
>>> Thanks for taking the lead on this. The code seems very reasonable and
>>> comprehensive. My only concern is around setting up an email address that
>>> links back to the core developers. This might create a thorny situation if
>>> the complaint is lodged against someone of that group and also sending a
>>> complaint to four dudes might make some people uncomfortable.
>>>
>>> Do you think there is any way around? For instance by picking 2 people
>>> that deal with such issues and making sure there is a bit of a gender
>>> balance there? (Happy to volunteer btw).
>>>
>>> Let me know what you think.
>>>
>>> Kind regards,
>>>
>>> Corinne
>>>
>>> ------------------------------
>>>
>>> Bigbang-dev mailing list
>>> Bigbang-dev at data-activism.net
>>> https://lists.ghserv.net/mailman/listinfo/bigbang-dev
>>>
>>>
>> _______________________________________________
>> Bigbang-dev mailing list
>> Bigbang-dev at data-activism.net
>> https://lists.ghserv.net/mailman/listinfo/bigbang-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ghserv.net/pipermail/bigbang-dev/attachments/20180413/d66ad88a/attachment-0001.html>