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

Define community constituency #71

Open
fricklerhandwerk opened this issue Apr 4, 2023 · 4 comments
Open

Define community constituency #71

fricklerhandwerk opened this issue Apr 4, 2023 · 4 comments

Comments

@fricklerhandwerk
Copy link
Contributor

fricklerhandwerk commented Apr 4, 2023

If the foundation is to be representative of something at all, this something needs to be defined.

  1. What constitutes a community member?
  2. How to get in?
  3. How to get out?

This may be as simple as:

  1. The person is listed somewhere
  2. A PR to that list is accepted by someone who is entitled.
  3. Renewal times out (you get removed from the list automatically) or you leave voluntarily.
@thufschmitt
Copy link
Member

Dupe of #62, closing to keep things tidy

@fricklerhandwerk
Copy link
Contributor Author

fricklerhandwerk commented Apr 4, 2023

No, this is not about the foundation board, this is about the community it's supposed to represent.

Or maybe the wording in #62 is misleading, because to me "part of the foundation" signals "representative" instead of "constituent".

@zimbatm zimbatm reopened this Apr 4, 2023
@zimbatm
Copy link
Member

zimbatm commented Apr 4, 2023

Some high-level thinking:

We want constituents to have a vested interest in the project's success. Assuming that the constituency is called upon for voting.

I would suggest defining that vested interest by a minimum level of contribution. This is a metric that can be gamed, and the foundation reserves the right to reject people who game the system. Another downside is that contribution is mostly measured by code contribution, so we also want a manual mechanism to recognize other types of contributions such as helping to organize events.

Contribution should also decay in some form, to avoid zombie members. Members can also explicitly opt out in case they don't want to participate in the project anymore.

That would be to enter the outer circle. Then each team would have their own criteria for entry and exit. For example, the infra team has stricter requirements than others due to the sensitive nature of the credentials they are holding.

@KiaraGrouwstra
Copy link

We want constituents to have a vested interest in the project's success.

The premise here seems the project's impact is limited to its users.
This seems to presume technology has no externalities on those not directly opting to use it, which might simplify the reality.
Now that military entities use NixOS, non-consensual externalities seem barely hypothetical.

As such, I would wonder how we would define project success, and why such measures of success should necessarily be considered both self-evident and uncontroversial.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants