MozillaFestival / open-leaders-7

Creative Commons Attribution Share Alike 4.0 International
21 stars 24 forks source link

Open source CMS privacy project #3

Open ghost opened 5 years ago

ghost commented 5 years ago

Project Lead: @webdevlaw

Mentor: David Ross

Welcome to OL7, Cohort F! This issue will be used to track your project and progress during the program. Please use this checklist over the next few weeks as you start Open Leadership Training :tada:.


Before Week 1 (Jan 31): Your first mentorship call

Before Week 2 (Feb 7): First Cohort Call (Open by Design)

Before Week 3 (Feb 14): Mentorship call

Before Week 4 (Feb 21): Cohort Call (Build for Understanding)

Week 5 and more

This issue is here to help you keep track of work as you start Open Leaders. Please refer to the OL7 Culture Track Syllabus for more detailed weekly notes and assignments past week 4.

ghost commented 5 years ago

Draft project mission: To create a common space for CMS teams to create and support privacy teams on the project and governance levels; provide guidance on implementing the Privacy by Design framework across the development workflow; share practical advice, code libraries, legal briefings, UX patterns, and useful resources; provide a space for general discussion, advice, and a sounding board for each other in support of our projects.

Draft project vision: Through collaboration, open source CMS projects can help transform our development communities into ones which empower user privacy through a positive and proactive approach to governance, standards, and tools, rather than a negative and reactive approach to privacy as a legal compliance obligation.

annefou commented 5 years ago

Very interesting. I know nothing about user privacy and will follow up your project as I am sure I will learn lots! I am working on user community development (#40) and I am interested to get guidance on this issues.

ghost commented 5 years ago

Thank you! You can follow our main project repo here https://github.com/joomla/cross-cms-compliance

Very interesting. I know nothing about user privacy and will follow up your project as I am sure I will learn lots! I am working on user community development (#40) and I am interested to get guidance on this issues.

ghost commented 5 years ago

We struggled a little bit on the diversity and inclusion, accessibility, and safety assignments for two reasons:

-One is that our project is a collaborative effort of contributors working across open source software projects, participating as representatives of our respective projects. We welcome all new participants to our working group - though we haven't had any yet! - but issues of diversity and inclusion and accessibility to our respective projects remain something which is not our battle to fight. Indeed, for some of us coming from less healthy projects, trying to establish guidelines on accessibility and diversity risks accusations of trying to take over projects, telling them what to do, or usurping others' roles within an established governance structure.

For now, our project working group is very happy to be a group of people with diverse roles, ages, and levels of experience across ten time zones, working in a very convival, collaborative, inviting work environment. We have already noticed how our support of each other is conveying the impression to others of us as a very clever bunch who have each others' backs, which is greatly helpful.

-On the Safety assignment, the issue there is that I have had experiences concerning my safety within the open source project I contribute to, including attacks, manipulative and undermining behaviour, and direct threats against me. That project is fully aware of it and has opted not to address those issues, nor does it have a code of conduct applicable to those situations. For those reasons, it proved very hard for me to approach the Safety exercise objectively. To use the airplane metaphor, I can't put an oxygen mask on someone else if I don't have one to put on myself first.

The way I opted to work on what I could work on, rather than fighting battles I cannot win, was to create a code of conduct for the working group which states that each participant is a representative of their own project, and therefore needs to work to their own project code of conduct as if it was an internal team. I then noted that in the event of a dispute or conflict, we would fall back on the Mozilla community participation guidelines as an authorative, but external, reference. I also noted that in the event of a dispute between participants, we would look to a third project to act as an independent arbiter.

That workaround settles the unlikely issues which would arise if there was a) someone in a situation like me who has no project code of conduct or safety mechanism to fall back on, or
b) the discomfort of a project which does have a code of conduct and safety mechanism having to evaluate an dispute concerning one of its own participants against someone from another project with a different code or process.

As difficult as this process was, it was helpful in forcing us to sit down and look at these issues, to realise that even talking about some of them risked dragging us down into hours of complaining about internal project dysfunction without being able to do anything about it, and from there, choosing instead to work on what we could address while making the wise decision to leave other processes to our larger projects.

ghost commented 5 years ago

Here is our #moz-sprint project: https://docs.google.com/document/d/1ICeWselGsFdUbKjXcOYXqWltSd1yDTT5iGMDreZKZDc/edit?usp=sharing

ghost commented 5 years ago

Project roadmap (work in progress) https://docs.google.com/document/d/1eYBOqcBSz0xm9tdOsnqNNVwN6NOuSedRbiG3XCRERmU/edit?usp=sharing

ghost commented 5 years ago

Case study draft: https://docs.google.com/document/d/1OYbpy8tNRO3KmiL7ECOUG3lvT750ZJ-KlApchiq85to/edit?usp=sharing