Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Working Open statement #3

Merged
merged 12 commits into from
May 22, 2019
53 changes: 53 additions & 0 deletions working-open.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
# Working Open

Hypha operates with democratic organizing principles informed by our [values](./values.md). As part of that, we've developed a set of guidelines for how (and exactly what) and why we work in the open.

## Why?

- In order to share and provide opportunities for self- and collective- learning as we work in solidarity with others seeking to create meaningful livelihoods.
dcwalk marked this conversation as resolved.
Show resolved Hide resolved
dcwalk marked this conversation as resolved.
Show resolved Hide resolved
- Not because "default to open" is an ideal in itself, but because it orients us toward negotiating a set of practices around our shared intentions.
dcwalk marked this conversation as resolved.
Show resolved Hide resolved
- Yet we recognize openly sharing might prevent frank and necessary discussion beneficial to our members, and so we want to clearly lay out our practices of consent and privacy.

# How and what?

- We currently accommodate redactions and going off-the-record for meeting notes. Participants can request to stop taking notes, or redact and correct notes after they have been taken.

Legend:
👀 view only
📝 view and participate

**Default open to public**:

- Scope: Organization
- Meeting notes (all hands, working groups) and final documents (handbook), on GitHub and other platforms 👀
- Aggregated financial statements 👀
- Scope: Project
- Project deliverables*, task tracking, meeting notes, and aggregated financial statements 👀

**This would include source repositories and code (e.g., on GitHub) and other process materials based on consensus on licensing and usage constraints.*

**Default open to members**:

- Scope: Organization
- Meeting notes and documents 📝
- Task tracking, project management (PM), and decision making (DM) tools 📝
- Finances (budget, expenses, and cash flow projections) and audit records 👀
- Potential opportunities and leads 📝
- Scope: Project
- Project proposal(s), statement(s) of work (in-progress/signed), in-progress deliverables, and finances (budget, expenses, and cash flow projections) 👀

**Default closed to specific working groups and project members**:

- Scope: Organization
- Full personal/financial information of members (e.g., home addresses, banking information, and social insurance numbers)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Full personal/financial information of members (e.g., home addresses, banking information, and social insurance numbers)
- Full personal/financial information of members (e.g. home addresses, banking information, and social insurance numbers)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I favour commas after e.g./i.e., it isn't a typo but a rather a distinct usage, see discussion: https://www.dailywritingtips.com/comma-after-i-e-and-e-g/ (I'd also say it fits in this text)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not saying this one is a typo, but I think without the comma is more common and so more likely to be consistently used. Same with 1 or 2 spaces after periods, etc. If you prefer having the comma we can aim for that in all our documents, but I definitely feel not having it is likely to stay consistent.

Copy link
Contributor

@patcon patcon May 17, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could use vale and dangerCI gem to encode our rules and do some of these evolving checks. Demo: patcon/dangerfile-test#1 (tho we'd poof a bot instead of using my github token :) )

Style rule: https://github.com/patcon/dangerfile-test/blob/master/ci/vale/styles/HyphaCoop/Eg.yml

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty indifferent about which, though I'll need to get used to using commas. But I'm fine with whatever conventions as long as we're on same page :)

(hence my appreciating the bot auto-correcting)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Commas after "For example" (e.g.) and "Further" (i.e.) tends to be grammatically correct when used without abbreviations. In my experience, but this is based on a lot of academic reading I recognize, commas are the more frequent usage.

- Personal/financial information involving external parties 📝
- Administration privileges including financial for services and infrastructure 📝
- Scope: Project
- Project sensitive data sets (especially all non-anonymized/identifiable) and critical infrastructure 📝

**Require consent before releasing**:

- Audio, visual, and video recordings (e.g., photographs or recorded interviews)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Audio, visual, and video recordings (e.g., photographs or recorded interviews)
- Audio, visual, and video recordings (e.g. photographs or recorded interviews)

- Chat transcripts
- Notes involving external parties and collaborators
- Materials from project retrospectives