Core Contributor rule set

What is the simplest rule set for becoming, staying, and no longer being a Core Contributor?

Earn it.

  • Show up. Participate for 6 months.
  • Own something. Take responsibility for a piece of OSD.
  • Ship something. Make a real contribution.

Join it (as a core contributor).

  • Get nominated. Any core contributor can nominate you.
  • Give it 7 days. The core gets a week to object.
  • No objection? You’re core. If there’s an objection, discuss it. If unresolved, simple majority decides.

Do it.

  • Stay present. Forum, messages, monthly meetings.
  • Own + ship. Take responsibility. Finish things.
  • Bring others in. Help new contributors learn the game and make things.

Leave it.

  • Step down. Leave whenever you want.
  • Disappear. Six months inactive = off core.
  • Break the rules. Violate the Code of Conduct = removal.

Edit, update, dunk on, kill it!

-Juhan

2 Likes

Link to current core contributor guidelines (but not having the “leave it”):

Additionally, I renamed the original thread to replace “team” with “maintainers”. Cause I think it’s important to stress that it’s mostly about doing the work, not about having the prestige of being in some “core team”.

For that, establishing the different teams like web team would also help of course. :slight_smile:

2 Likes

What are the “special rights” of maintainers, other than voting on accepting maintainers, RW access to repos, and?

Mostly to be in a signal group to coordinate things. It might also be okay-ing expenses on open collective, but I am unsure (@Erioldoesdesign ?)

Yep Open Collective admin rights is also a thing some core maintainers have which allows for the 2 person approval of invoices and expenses and moving donation money around between specific projects there too.

Additionally to the access there’s like access to social accounts, access to web hosting, other infrastructure etc. etc.

I think there’s also some clarification that could be done around advocacy/sustainability of open source design as a community that i would define more of a ‘optional responsibility’ for maintainers e.g. I would hope that maintainers are taking on some responsibility for ‘spreading the word’ about open source design as a community and also just as a thing generally.

But i think it’s good to clarify that that is not an explicit criteria for maintainers and more of me expressing an expectation i have that could (should?) be challenged