Bylaws

[simonv3]

I've been drafting some bylaws, focusing on how we reach consensus.

http://piratepad.net/opensourcedesign-bylaws

I think the situation with the logo highlights that we need a better process for reaching decisions as a community. Voting isn't perfect, but it's a good last resort if nothing else gets done.

Please add your own thoughts, or feedback here or there. Also let me know if you think this is out of line, and you think the community doesn't need anything like this. It could be that I mis-interpreted our needs.

@bnvk Can you merge in our code of conduct that you drafted taking into consideration people's responses to it? I think that's an excellent case and point of initiative when something needs to happen.

[jancborchardt]

@simonv3 I made some minor comments and additions. Looks good!

[simonv3]

I've moved this to

https://oasis.sandstorm.io/shared/4pKY8ACQrCKiGmxsSgKoRIelKxm01w60JsWlV660hoD

[evalica]

We definitely need a way to vote, although this process can be lengthy. It's still not clear if when we need voting we need to wait 2 weeks or 3 days. Anyway the time frame needs to be longer than 1 week since in OS people are usually reading things in the week-end.

Also on other communities votes are send on the mailinglist using a tag like '[VOTE]' in order to capture the members attention and decide the start time for the voting period. Since we are not having a mailinglist and we are using GitHub for the communication purpose, I don't know what the alternative would be. Maybe creating an issue with the 'VOTE' in the description. Anyway these are just thoughts.

Thanks for raising the subject.

[evalica]

'Bylaws' could be renamed to 'Voting rules' or something else :) since you might not understand what this topic is about.

[simonv3]

Crap. I think I may have deleted that grain while clearing up my sandstorm clutters. And the trash is empty :/

Old text from the piratepad:

# By Laws
 
## Mission
 
> We are a community of designers and developers pushing more open design processes and improving the design of open source apps.
 
## Reaching Consensus
 
* We're an organization of volunteers spread around the globe with no hierarchy. 
* We still want to be able to make decisions.
* We want to encourage people to take initiative.
This is hard if we don't have set rules for doing so.
 
### Proposed Solution
 
We work well with GitHub. We know that it isn't an open tool, but it's a social network that is familiar and encourages wide participation, and is widely used by FOSS projects. 
 
* Minor changes to the website and organization will be maintained by github issues and pull requests.
* Major organizational changes (logos, umbrella projects, etc) will have to go through a set process.
 
Before taking initiative, here's a useful checklist:
* [ ] Can you name the problem?
* [ ] Have you seen other people discuss it?
* [ ] Have you asked on IRC or on GitHub whether it's been discussed before?
* [ ] Can you personally see this through to the end?
* [ ] Can you find people who could offer opinions or feedback on your initiative?
* [ ] Do you think this is a major enough initiative that it would require community feedback?
 
  1. Name the problem.
  3. If the problem needs a approval from the wider community (eg, accept a project as an umbrella project) then we will put it to a vote after a certain amount (TODO: how long?) of discussion on it has happened. 
  The vote will be open for two weeks.
  TODO: We need a list of THINGS THAT NEED COMMUNITY APPROVAL topics.
  2. If there is no clear aproval then a call for a volunteer committee will be put out. 
  If during the consensus solution discussion someone steps forward to organize such a commitee priority will be given to that committee. Membership of the committee should be diverse and hold a wide variety of opinions.
  3. If no volunteer committee comes forward, and no consensus is reached, things will be put to a vote. The vote will be single transferable vote if that's appropriate (if there are multiple options). If it's a yes / no vote than a 51% majority will be needed.
  4. A committee can work on the process, but they're administration, not decision makers. 
  Final decisions should still lay with the community
 
THINGS THAT NEED COMMUNITY APPROVAL (or some form of it)
Generally these are things that you feel uncomfortable deciding for the rest of the community. For example:
Drastic design changes for the website
Community logo
What projects to have underneath the open source design umbrella of projects (front page projects)
…
 
THINGS THAT DON'T NEED COMMUNITY APPROVAL
Adding content to the existing structures:
Adding people to the organization
Adding projects to the job board
Adding resources to the resources repository
etc
 
Stray thoughts: 
 
  We want to encourage people to take initiative. 
  If someone thinks they can lead the charge on something they should do  so after asking whether anyone else is already doing so.
  If no one answers within three days, you have a green light. 
  If it involves a type of issue listed in THINGS THAT NEED APPROVAL, keep that in mind while working on it.
  
## Code of Conduct
 
Every member of our community will abide by our code of conduct. You are a member of our community when you interact with our website, the github organization, our presence on other websites, and other members of our community. http://opensourcedesign.net/code-of-conduct/
 
## Open Source Software and What We Use
 
We're a community that wants to push the use of open tools to make open source software better. One of our goals is spreading knowledge of open source and open source d

[bnvk]

Crap. I think I may have deleted that grain while clearing up my sandstorm clutters. And the trash is empty :/

Ahhhhh... noooo... DATA LOSS. Sad panda. Sad Keanu :(

This is why I advocate for using .md files and saving in Git as a branch or what have you. Sorry to hear that amigo.

EDIT: Oops, I didn't see the paste in email for some reason. Transfering this to markdown now.

[bnvk]

Ok @simonv3 added your page with some mild formatting

http://opensourcedesign.net/by-laws/

[simonv3]

Awesome. Thanks @bnvk. You're 100% right about the data loss and .md.

I edited in the .md stuff which is probably why you didn't see it in the e-mail.

[jancborchardt]

So we have the page, should we link it from the About page? And we add it to the OSI application, then we can close this issue :)

[grahamperrin]

Showcase existing open source design material

When that line is read in isolation, the word material is quite vague, generic.

Can anyone think of a more descriptive word (or short phrase) that might make that line, alone, more descriptive?

(At the time of writing: I can not, sorry!)

[ei8fdb]

Hea @simonv3, where is the most up-to-date copy of the proposed bylaws? Is it the piratepad listed above? Or somewhere else? Ta!

[simonv3]

@ei8fdb here: http://opensourcedesign.net/by-laws/

which lives here: https://github.com/opensourcedesign/opensourcedesign.github.io/blob/master/by-laws.md

[grahamperrin]

'Bylaws' could be renamed …

:+1:

When I first found /by-laws/ I thought that By-laws was not the best title for the page content.

The mission statement belongs elsewhere. Repetition dilutes the page. If the mission is properly promoted elsewhere (not at /by-laws/) then still, by-laws is not the phrase that I would choose.

I associate laws and by-laws with conduct.

Resist the temptation to merge information that is organisational and/or operational (for want of better expressions) into a code of conduct. Like it or not: realistically, you should expect a great percentage of readers to ignore anything that is labelled code of conduct.

I see the Code of Conduct section as unnecessary; the two sentences dilute the essence of page.

The longer, the more dilute, any page: the greater the likelihood that readers will not read to the foot (which links to the Code).

… One of our goals is spreading knowledge of open source and open source design. …

Not quite. The word knowledge appears nowhere amongst the goals.

… link it from the About page? …

On one hand: yes, I think so. The seven numbered points at /about/ are – first and foremost – goals (that's how they're described at the home page), so:

• How We Plan To Achieve … and the text that follows could become a link, Realisation of goals

– linking to, maybe, to http://opensourcedesign.net/organisation/

I treat involvement as essential to how a group organises itself.

On the other hand:

… the OSI application …

– my readings of the multiple OSI-related issues in GitHub are incomplete. Conscientiously, I should digest more of the writings before forming a clearer opinion of whether the essence of https://github.com/opensourcedesign/opensourcedesign.github.io/blob/master/by-laws.md might suit an /organisation/ path.