About Us | Open Source Design

By-laws

Mon, 01 Jan 0001 00:00:00 +0000

Mission

We are a community of designers and developers pushing more open design processes and improving the design of open source and free software.

You can read more here

Open

We are an open community. Any conversation or decisions that impact the future of our community need to be available to as large a part of our community and the general public as possible.

What does that mean?

Conversations that impact the community should not happen in invite-only spaces.
Content should be accessible (preferably ADA accessible, i.e. text to speech software should be able to parse it)
As best as we can we should use software that follows Free, Libre, and Open definitions and standards.
This doesn’t apply to conversations that require a high level of trust and confidentiality. An example of this is breaches to our Code of Conduct. See how to do that in Reporting Violations.

Reaching Consensus

We’re an organization of volunteers spread around the globe with as little hierarchy as possible.
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 our Discourse forum 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? A good place to start is the people listed on the core e-mail address
Do you think this is a major enough initiative that it would require community feedback?

Then, once you’ve identified the problem:

Name the problem to the community.
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 open for two weeks. TODO: We need a list of THINGS THAT NEED COMMUNITY APPROVAL topics.
If there is no clear approval then a call for a volunteer committee will be put out. If during the consensus solution discussion someone steps forward to organize such a committee priority will be given to that committee. Membership of the committee should be diverse and hold a wide variety of opinions.
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.
A committee can work on the process, but they’re administration, not decision makers. Final decisions should still lay with the community

Community Approval

Things that need community approval

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

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.

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 design.

Read more on opensourcedesign.net →

Code of Conduct

Mon, 01 Jan 0001 00:00:00 +0000

In order to keep the Open Source Design community warm, welcoming, and safe place we ask that all participants read and adhere to the following code of conduct.

Be excellent to each other

Please treat each other, as well as the public, in an excellent way. What it means to “be excellent” is the following:

Be radically inclusive to existing members and newcomers looking to learn or participate
Be totally respectful of each others abilities, interests, and personal differences
Be exceedingly kind even in moments of disagreement while working towards consensus
Educate and illuminate others with something you know more about
Be open to feedback from others in the community, be it technical skill or interpersonally

These traits exemplify the type of community we strive for with Open Source Design. We want a diverse community where members treat each other excellently, at all times.

We want Open Source Design to be diverse because we A) believe in equality and B) know that diversity leads to healthier culture, which outputs better creativity.

Don’t be a mean or a not nice person

The following are behaviors that are known to exclude and make other demographics of people feel unwelcome. Please do not do the following.

Don’t be offensive

If you think you are offending someone for whatever reason, STOP immediately. If you’re uncertain, ask a core community member (in private message). Asking for guidance will show good faith that you are striving to uphold our code of conduct.

Don’t discriminate against anyone

Please be especially sensitive and aware of others who are different from you. Don’t make jokes, offhand comments, or name your projects in ways that can be offensive relating to, but not limited to, the following topics

Age
Culture
Ethnicity
Gender identity & expression
Nationality
Physical disabilities or differences
Mental disabilities or differences
Politics
Race
Religion
Sex
Sexual orientation
Socio-economic status
Subcultural affiliation

Discriminatory comments or naming of projects that relate to any of the above topics are the most common forms of abuse. Thus we consider violations relating to these topics to be severe violations of our code of conduct.

Don’t sexualize your work

This is another tricky point as some people see no harm in naming a code libraries things like bikini.js or crotchlessChaps.js or fat-man.rb or leaving comments in their code like A sexy ass variadic function. These little things may seem harmless, but can make others of different orientations, ideologies, or life experiences feel very uncomfortable. It is best to avoid such things as:

Don’t use overtly sexual usernames, or project names
Don’t refer to others in a sexualized way
Refrain from comments with sexual undertones and metaphors

Don’t make unwelcome sexual advances

Most of our community are adults and should know when it’s ok to flirt with other adults. However, we’re also an online community whereby many people don’t know each other in real life. Many of us come from different cultures. What might be seen as lighthearted flirting in one culture, might be extremely offensive to another culture. This discomfort causes people to not participate in communities. Therefore it’s best to not do it. Open Source Design is a community about bringing great design to open source software, let’s keep it focused on that.

Artificial Intelligence and Automated Tools

As AI-assisted design and development tools such as Codex, Claude Code, etc. become increasingly common in open source workflows, we ask that community members and contributors apply the same values outlined in this Code of Conduct when using these tools. Contributors remain responsible for reviewing and validating any AI-generated code or content before submitting it to the project.

Where this CoC is upheld

This code of conduct especially pertains to our online community platforms (GitHub: @opensourcedesign, Mastodon: @opensourcedesign@mastodon.social, Discourse Forum: discourse.opensourcedesign.net) as well as our offline events like the FOSDEM Open Source Design room, the FOSSASIA Design track, the Open Source Design Summit and local meetups. But it also pertains to your personal public communications and views.

Being a respectful contributor to Open Source Design by day and a ragging (or even mild) neo-nazi by night is still grounds for expulsion. Some people see this as impinging on personal freedoms, we disagree, sorry.

Consequences for violations

If a participant engages in behavior violating this code of conduct, the core members of this community may take any action they deem appropriate. Actions may range from a simple warning to the most drastic: expulsion from the community, exclusion from any interaction, and loss of all rights in the community.

Reporting violations

If you are aware of a violation of our code of conduct, please report it by e-mailing our core contributors at core at opensourcedesign.net. They will investigate as soon as possible. If you would like to remain anonymous in the report, please note this.

For the list of who receives e-mail sent to that address, check this issue discussing the core e-mail address.

Decisions about consequences

Decisions about consequences of violating this code of conduct are made by the community’s core members and will not be discussed with the person responsible for the violation until a decision has been reached.

Additions, amendments, and feedback

It is foreseeable that this code of conduct will need additions and to be improved upon. Online culture changes, new views and sensitivities emerge which need to be taken into account. In order to add or modify our Code of Conduct, please fork and send a pull request or open an issue with your proposed changes. Our community will happily review it for inclusion.

Credits

This Code of Conduct was based on the Ada Initiative’s HOWTO design a code of conduct for your community, as well as CoCs from the Hoodie and Django projects.

Read more on opensourcedesign.net →

Governance

Mon, 01 Jan 0001 00:00:00 +0000

Why

In a perfect world all the FOSS loving developers and designers would write all the code and push all the pixels however they desired and no problems would ever arise. However, problems do arise, and this page is a place to document and iterate on how we reach consensus and resolve conflicts in ways which make the most of differences and benefit the greater good of the community and its goals.

Reaching Consensus

Discussion

Ideally consensus can usually be reached by discussing and listening to one another. A good example of this was:

Proposed front page layouts

However, just discussing things is not always enough, or an issue is too long, sprawling, or many options to simply make a decision. Voting often helps here.

Voting

When multiple people are contributing to solving one issue and there is no clear best option, as was the case of creating the OSD logo, it is best to draw things to a vote. For reference, see:

Stagnant Tasks

Often times very needed (and promising) ideas or projects get started but then stagnate and slump into non completion. If you come across something that seems stagnant and it’s of interest to you, please feel free to proceed working on it with the following tips:

Dos

Do check on the forum if anyone can give you advice or backstory on the issue
Do leave a comment on the issue expressing your interest
Do @mention the creator of the issue and / or last person working on it
Do reach out to creator / last person working on it via email

Don’t

Don’t just start working on an issue without telling anyone
Don’t deviate drastically from stated goals (to the best of your understanding)

Read more on opensourcedesign.net →

Manifesto

Mon, 01 Jan 0001 00:00:00 +0000

Open Source Design Manifesto

1. Open Source Design connects open source and design

We connect open source workflows with human-centered design. We value usability, empowerment, sustainability, collaboration and transparency.

2. Open Source Design is inclusive

We are inclusive to newcomers and act with humility. We are open to constructive criticism, discourse and feedback. We have a diverse representation of people in our projects and communities.

3. Open Source Design is collaborative and remixable

Design is a team effort and multiple perspectives provide a richer result. Every work builds upon prior information and intellectual work. We creatively copy and remix with attribution and gratitude.

4. Open Source Design is empathic

Our responsibility is to make products usable for a diverse audience. Our work is universally accessible.

5. Open Source Design is part of a process

Design is a continuous part of a larger development process. It is informed by research and testing, and starts at the very beginning of a product.

6. Open Source Design is ethical

We design with respect and ethics in mind. People’s privacy and time is honored. Our design processes and tools complement these values.

7. Open Source Design is educational

We share knowledge and teach skills. We help designers get involved in open source, and help open source developers make their products better through good design.

8. Open Source is respectful.

We encourage creators respecting others and their own work. We believe respectful citations and references are cornerstone for any kind of collaborative work.

Read more on opensourcedesign.net →

Moderation dashboard

Mon, 01 Jan 0001 00:00:00 +0000

Read more on opensourcedesign.net →