Archived
15
23
Fork
You've already forked meta
6

[AGREEMENT] Disolving and re-creating the security team #140

Closed
opened 2023年01月30日 18:16:29 +01:00 by Ghost · 4 comments

Applications

Rationale

The security team was created at the very begin of the Forgejo project and has not been approved by the Forgejo community. This needs to change given how critical it is to the day to day operations. Now that there exists an embryo of decision making, I propose it is done as follows.

  • A discussion happens in this issue regarding how the security team is to be appointed
  • Forgejo community members apply to be part of the future security team (following the examples set by the existing applications or whatever they think more appropriate).
  • The larger Forgejo community is actively asked for feedback when there is at least three applicants (the assignees of this issue are accountable to make that happen)
  • When at least three members meet the approval of the community, the existing security team is disolved and hand over the credentials to the newly formed team.

Does that sound like a sensible way to create a legitimate security team?

### Applications * [fnetx](https://codeberg.org/forgejo/meta/issues/141) * [gusted](https://codeberg.org/forgejo/meta/issues/142) * [dachary](https://codeberg.org/forgejo/meta/issues/139) ### Rationale The security team was created at the very begin of the Forgejo project and has not been approved by the Forgejo community. This needs to change given how critical it is to the day to day operations. Now that there exists an [embryo of decision making](https://codeberg.org/forgejo/meta/src/branch/readme/DECISION-MAKING.md), I propose it is done as follows. * A **discussion** happens in this issue regarding how the security team is to be appointed * Forgejo community members **apply** to be part of the future security team (following the examples set by the existing applications or whatever they think more appropriate). * The larger Forgejo community is **actively asked for feedback** when there is at least three applicants (the assignees of this issue are accountable to make that happen) * When at least three members meet the approval of the community, the existing security team is disolved and hand over the credentials to the newly formed team. Does that sound like a sensible way to create a legitimate security team?
Contributor
Copy link

I don't know when the next election is going to happen but for the record:

I'm likely not available for at least this team election (so therefore would leave the security team and trigger an update to 65df5701dc/TEAMS.md (security) ).

Background

I've started a freelance company earlier this month and need some time to bootstrap it. Before I don't have any sense of income stream I can't focus on Forgejo. NLNet is yet to get back to me.

That being said, I can imagine to re-join in the future.

Once I learn about a re-elected Security Team I pledge to reach out to them to inquiry which secrets to remove from my password manager as well as backups I hold. Nevertheless a rotation might be a recommended step to take.

Good luck!

I don't know when the next election is going to happen but for the record: I'm likely not available for at least this team election (so therefore would leave the security team and trigger an update to https://codeberg.org/forgejo/meta/src/commit/65df5701dca06819bd07df1bd7a4658a0838af57/TEAMS.md#security ). ## Background I've started a freelance company earlier this month and need some time to bootstrap it. Before I don't have _any_ sense of income stream I can't focus on Forgejo. NLNet is yet to get back to me. That being said, I can imagine to re-join in the future. Once I learn about a re-elected Security Team I pledge to reach out to them to inquiry which secrets to remove from my password manager as well as backups I hold. Nevertheless a rotation might be a recommended step to take. Good luck!
Contributor
Copy link

I'm okay with the proposal (for now, since the governance system doesn't yet have instructions for team formation).

I want to highlight the following 3 decisions:

  1. What are the criteria for being in the security team? Which traits/characterstics do we expect to have, in people who would be in the security team? Let's gather criteria in the comments

  2. Once we have a list of criteria, who has the power to modify them in the future? Is it a whole-organization thing, or will the security team have the power to decide?

  3. Can the security team take in a new member, without needing approval of the whole organization?

I suggest that if time passes we don't get much input, just keep the current security team, and have the security team make the list of criteria if willing and able.

(I'm looking into team formation stuff, hoping to come up with a more formal process soon)

I'm okay with the proposal (for now, since the governance system doesn't yet have instructions for team formation). I want to highlight the following 3 decisions: 1. What are the **criteria** for being in the security team? Which traits/characterstics do we expect to have, in people who would be in the security team? **Let's gather criteria in the comments** 2. Once we have a list of criteria, who has the power to modify them in the future? Is it a whole-organization thing, or will the security team have the power to decide? 3. Can the security team take in a new member, without needing approval of the whole organization? I suggest that if time passes we don't get much input, just keep the current security team, and have the security team make the list of criteria if willing and able. (I'm looking into team formation stuff, hoping to come up with a more formal process soon)

I'm fine with the idea that each Forgejo community member looks at the list of applicants, read their pledge, read their background and decide if they make a credible security team. In other words, the criteria is that the team is composed of the subset of applicants that meet the agreement of the community.

I thought for a while about the drawback of that approach but could not find any.

Here is an example of an objection "An applicant must be trusted to keep a secret by the other members of the team, surely that must be a criteria". Now imagine if Jane Doe posts an application and they have a really good background, only nobody knows her. I then fully expect that at least one person in the Forgejo community will comment on her application expressing reservations. They could for instance write: "I feel there is a need for a significant history of participation and trust before entering the security team, you have a fantastic background and I look forward to getting to know you better so you can become part of the security team eventually. Now seems too soon, do you mind waiting?". It is of course also possible that nobody will express such a reservation and that the person becomes part of the security team. But if that happens, it means something is so deeply broken that it will only be the tip of the iceberg and any amount of pre-defined criteria won't help.

Another objection could be that it is common practice for an organization to define a position by setting some kind of job posting, with criteria included. So that candidates know what to expect and know if they are a fit. But this is not a paid position, it is a volunteer position so the logic is reversed. When someone comes in with a desire to participate, the decision the Forgejo community needs to make is whether this gift of their valuable time is in the best interest of the project.

Yet another objection is that because of the lack of criteria an applicant may discover after being accepted in the team that it is not what they expected. Since it is the nature of the security team to work in secret, such an adjustment will inevitably exist, criteria or not. And here again the volunteer nature of the position helps: the person can withdraw at any time, they are not bound by a contract that would have them forced into an uncomfortable position for an extended period of time.

I thought about more objections along the lines of perpetuating a elites, how fuzziness creates a tyranny, etc. And I will happily discuss each of those but I'm not doing that here to keep this comment brief.

The bottom line is that I believe the way the decision process is setup in Forgejo and the existing security team creates a healthy context that does not require defining additional criteria.

I'm fine with the idea that each Forgejo community member looks at the list of applicants, read their pledge, read their background and decide if they make a credible security team. In other words, the criteria is that the team is composed of the subset of applicants that meet the agreement of the community. I thought for a while about the drawback of that approach but could not find any. Here is an example of an objection "An applicant must be trusted to keep a secret by the other members of the team, surely that must be a criteria". Now imagine if Jane Doe posts an application and they have a really good background, only nobody knows her. I then fully expect that at least one person in the Forgejo community will comment on her application expressing reservations. They could for instance write: "I feel there is a need for a significant history of participation and trust before entering the security team, you have a fantastic background and I look forward to getting to know you better so you can become part of the security team eventually. Now seems too soon, do you mind waiting?". It is of course also possible that nobody will express such a reservation and that the person becomes part of the security team. But if that happens, it means something is so deeply broken that it will only be the tip of the iceberg and any amount of pre-defined criteria won't help. Another objection could be that it is common practice for an organization to define a position by setting some kind of job posting, with criteria included. So that candidates know what to expect and know if they are a fit. But this is not a paid position, it is a volunteer position so the logic is reversed. When someone comes in with a desire to participate, the decision the Forgejo community needs to make is whether this gift of their valuable time is in the best interest of the project. Yet another objection is that because of the lack of criteria an applicant may discover after being accepted in the team that it is not what they expected. Since it is the nature of the security team to work in secret, such an adjustment will inevitably exist, criteria or not. And here again the volunteer nature of the position helps: the person can withdraw at any time, they are not bound by a contract that would have them forced into an uncomfortable position for an extended period of time. I thought about more objections along the lines of perpetuating a elites, how fuzziness creates a tyranny, etc. And I will happily discuss each of those but I'm not doing that here to keep this comment brief. The bottom line is that I believe the way the decision process is setup in Forgejo and the [existing security team](https://codeberg.org/forgejo/meta/src/branch/readme/TEAMS.md#security) creates a healthy context that does not require defining additional criteria.

It has been two weeks since the applications were published and they had around 10 eyes from the Forgejo community on them which is good. However, since it is an important agreement, I feel there is a need to actively seek participation from more people and I posted the following in the development chat:

Aminda (she/they 🏳️‍⚧️ MSC1769|MSC3189): Aravinth circlebuilder fr33domlover KaKi87 Max Kratz Earl Warren Nathanael (Easter-Eggs) rdwz There are three candidates for the Forgejo security team (otto, gusted and myself) waiting for your opinion on their application. The security team plays an important role and its members need your voice to be legitimate. If an applicant meets your approval just add a 👍️ If you have no opinion for whatever reason you can 👀 to express that you took a look, to acknowledge that you are aware of the existence of this application. If you have reservations of any kind, make sure you post a comment explaining what they are. Thanks for your help in gathering a wide consensus 🙏

It has been two weeks since the applications were published and they had around 10 eyes from the Forgejo community on them which is good. However, since it is an important agreement, I feel there is a need to actively seek participation from more people and I posted [the following in the development chat](https://matrix.to/#/!zpNKWqkiEOyljSMQDK:matrix.org/4ドルPS0Q99NaqGV8lve8Jm8urdoL2Ong2d3NlrWvy4svas?via=exozy.me&via=matrix.org&via=semper.tel): > Aminda (she/they 🏳️‍⚧️ MSC1769|MSC3189): Aravinth circlebuilder fr33domlover KaKi87 Max Kratz Earl Warren Nathanael (Easter-Eggs) rdwz There are three candidates for the Forgejo security team ([otto](https://codeberg.org/forgejo/meta/issues/141), [gusted](https://codeberg.org/forgejo/meta/issues/142) and [myself](https://codeberg.org/forgejo/meta/issues/139)) waiting for your opinion on their application. The security team plays an important role and its members need your voice to be legitimate. If an applicant meets your approval just add a 👍️ If you have no opinion for whatever reason you can 👀 to express that you took a look, to acknowledge that you are aware of the existence of this application. If you have reservations of any kind, make sure you post a comment explaining what they are. Thanks for your help in gathering a wide consensus 🙏
Commenting is not possible because the repository is archived.
No Branch/Tag specified
readme
No results found.
Labels
Clear labels
[Decision] Building proposal(s)
We're in a decision-making process, buiding one or more proposals to address the shared aim based on the criteria
[Decision] Gathering criteria
We're in a decision-making process, gathering criteria, considerations and needs
[Decision] Integrating concerns
We're in a decision-making process, working with a proposal, trying to integrate concerns and create modifications/support such that the proposal works for everyone
Accessibility
Relates to Accessibility (a11y) of product, project and process.
Agreement proposal
Forgejo agreement proposal, following a discussion
Communication
Relates to all channels, social media, website, blog posts.
Election
Process of appointing a person into a role or team (if choosing people just for a specific one-time task, use the Entrustment label)
Entrustment
Process of choosing/approving specific people to do a critical/high-impact one-time task (if choosing people for an ongoing role/team, use the Election label)
Governance
Relates to processes, procedures and decision-making.
Meeting
An upcoming team meeting
User research - Accessibility
Requires input about accessibility features, likely involves user testing.
User research - Blocked
Do not pick as-is! We are happy if you can help, but please coordinate with ongoing redesign in this area.
User research - Community
Community features, such as discovering other people's work or otherwise feeling welcome on a Forgejo instance.
User research - Config (instance)
Instance-wide configuration, authentication and other admin-only needs.
User research - Errors
How to deal with errors in the application and write helpful error messages.
User research - Filters
How filter and search is being worked with.
User research - Future backlog
The issue might be inspiring for future design work.
User research - Git workflow
AGit, fork-based and new Git workflow, PR creation etc
User research - Labels
Active research about Labels
User research - Moderation
Moderation Featuers for Admins are undergoing active User Research
User research - Needs input
Use this label to let the User Research team know their input is requested.
User research - Notifications/Dashboard
Research on how users should know what to do next.
User research - Rendering
Text rendering, markup languages etc
User research - Repo creation
Active research about the New Repo dialog.
User research - Repo units
The repo sections, disabling them and the "Add more" button.
User research - Security
User research - Settings (in-app)
How to structure in-app settings in the future?
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
forgejo/meta#140
Reference in a new issue
forgejo/meta
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?