Archived
15
23
Fork
You've already forked meta
6

Have a source-of-truth public list of Forgejo Organization members #147

Closed
opened 2023年02月01日 14:01:58 +01:00 by fr33domlover · 11 comments
Contributor
Copy link

I believe it's really important for transparency, clarity and trust (among team members and between team and wider community), that we maintain a reliable public list of all members on the Forgejo Organization.

PROPOSAL: At https://codeberg.org/forgejo, mark everyone's membership as visible. Including "meta" users like forgejo-ci. And have an agreement, that whenever we add a new person to the organization, their membership is set to be visible.

Anyone has concerns about this proposal? Or a different idea that you believe will serve us better?

If so, please comment :) If not, please mark your membership as visible.

I believe it's really important for transparency, clarity and trust (among team members and between team and wider community), that we maintain a reliable public list of all members on the Forgejo Organization. PROPOSAL: At <https://codeberg.org/forgejo>, mark everyone's membership as visible. Including "meta" users like forgejo-ci. And have an agreement, that whenever we add a new person to the organization, their membership is set to be visible. Anyone has concerns about this proposal? Or a different idea that you believe will serve us better? If so, please comment :) If not, please mark your membership as visible.
Contributor
Copy link

I do object.

It's one thing to encourage visible membership. But there might be reason we are not aware of that will make people prefer not to be listed publicly.

In the sense of an inclusive community I demand that the membership not to be enforced to be visible.

That has a second effect as well:
Do we want to exclude people not on Codeberg from our community?
In what regard would Codeberg be better than GitHub then? (As central hub).
What about those that will go out and speak in our favour? But don't interact with git-based tooling in any way.

Federation would allow us to work across instances. I'm very much in favour to see this reflected in how we define our community.

I do object. It's one thing to encourage visible membership. But there might be reason we are not aware of that will make people prefer not to be listed publicly. In the sense of an inclusive community I demand that the membership not to be enforced to be visible. That has a second effect as well: Do we want to exclude people not on Codeberg from our community? In what regard would Codeberg be better than GitHub then? (As central hub). What about those that will go out and speak in our favour? But don't interact with git-based tooling in any way. Federation would allow us to work across instances. I'm very much in favour to see this reflected in how we define our community.
Contributor
Copy link

In the sense of an inclusive community I demand that the membership not to be enforced to be visible.

Can you explain why inclusiveness is affected by enforcing visibility? Taken in account we are talking about logins, not necessarily known persons.

That has a second effect as well:
Do we want to exclude people not on Codeberg from our community?

The proposal speaks literally about Forgejo Organization, no about community. Community includes users, instance admins, even Gitea because is part of the ecosystem.

> In the sense of an inclusive community I demand that the membership not to be enforced to be visible. Can you explain why inclusiveness is affected by enforcing visibility? Taken in account we are talking about logins, not necessarily known persons. > > That has a second effect as well: > Do we want to exclude people not on Codeberg from our community? The proposal speaks literally about Forgejo Organization, no about community. Community includes users, instance admins, even Gitea because is part of the ecosystem.
Contributor
Copy link

Can you explain why inclusiveness is affected by enforcing visibility?

Sure.

A friend of mine belongs to a minority. I'm asked to not give away the sex. It would affect the life of that person if every organisation would display the membership of that person. Therefore there is contributions because of a sense of belonging. But the profile is private.

I myself have organisations on GitHub I'm member of but won't show up there publicly.

Taken in account we are talking about logins, not necessarily known persons.

Logins as in profiles? I'm not sure what are you referring to. A person can have multiple profiles. There are technical accounts as well.

The proposal speaks literally about Forgejo Organization, no about community.

Good point. So organisation (I prefer BE) as in the concept of what is coded in Gitea / Forgejo. The second effect is less of importance then.

> Can you explain why inclusiveness is affected by enforcing visibility? Sure. A friend of mine belongs to a minority. I'm asked to not give away the sex. It would affect the life of that person if every organisation would display the membership of that person. Therefore there is contributions because of a sense of belonging. But the profile is private. I myself have organisations on GitHub I'm member of but won't show up there publicly. > Taken in account we are talking about logins, not necessarily known persons. Logins as in profiles? I'm not sure what are you referring to. A person can have multiple profiles. There are technical accounts as well. > The proposal speaks literally about Forgejo Organization, no about community. Good point. So organisation (I prefer BE) as in the concept of what is coded in Gitea / Forgejo. The second effect is less of importance then.
Contributor
Copy link

Taken in account we are talking about logins, not necessarily known persons.

Logins as in profiles? I'm not sure what are you referring to. A person can have multiple profiles.

That's the point, the proposal asks to put profiles in public status, not necessarily people.

By the way, talking about sex is a misnomer when talking about inclusivity. A commonly used inclusive term is gender, but it is not part of the profile, so I still don't see a good reason for the objection.

> > Taken in account we are talking about logins, not necessarily known persons. > > Logins as in profiles? I'm not sure what are you referring to. A person can have multiple profiles. That's the point, the proposal asks to put profiles in public status, not necessarily people. By the way, talking about *sex* is a misnomer when talking about inclusivity. A commonly used inclusive term is gender, but it is not part of the profile, so I still don't see a good reason for the objection.
Contributor
Copy link

A commonly used inclusive term is gender

I'm aware of the difference. My word was chosen accordingly.

but it is not part of the profile

It might be deduced from the nickname by drawing associations to other online presences.

> A commonly used inclusive term is gender I'm aware of the difference. My word was chosen accordingly. > but it is not part of the profile It might be deduced from the nickname by drawing associations to other online presences.

I think @Ryuno-Ki's objections are reasonable and I share similar reservations.

I think @Ryuno-Ki's objections are reasonable and I share similar reservations.

I believe it's really important for transparency, clarity and trust (among team members and between team and wider community), that we maintain a reliable public list of all members on the Forgejo Organization.

The https://codeberg.org/forgejo/meta/src/branch/readme/TEAMS.md is the source of truth of all people with a role in Forgejo.

It was created because the way the Forgejo teams membership is implemented does not provide a convenient way to display who is where. This has been discussed already a few weeks ago.

Is there is a specific problem with how this file is maintained at the moment?

> I believe it's really important for transparency, clarity and trust (among team members and between team and wider community), that we maintain a reliable public list of all members on the Forgejo Organization. The https://codeberg.org/forgejo/meta/src/branch/readme/TEAMS.md is the source of truth of all people with a role in Forgejo. It was created because the way the Forgejo teams membership is implemented does not provide a convenient way to display who is where. This has been discussed already a few weeks ago. Is there is a specific problem with how this file is maintained at the moment?
Contributor
Copy link

This has been discussed already a few weeks ago.

I'm catching up with the last two months, so pardon me for not being aware of this.

> This has been discussed already a few weeks ago. I'm catching up with the last two months, so pardon me for not being aware of this.

@Ryuno-Ki my comment was for @fr33domlover's benefit. I did not expect you knew about that discussion.

@Ryuno-Ki my comment was for @fr33domlover's benefit. I did not expect you knew about that discussion.
Member
Copy link

Is there is a specific problem with how this file is maintained at the moment?

I do not believe so, therefore I'm in favor of closing this issue as already resolved.

I demand that the membership not to be enforced to be visible.

Membership is visible no matter what : as soon as one authored anything (reaction, comment, issue, commit, PR), one is visible.

The list, as abovementioned, is about transparency.

> Is there is a specific problem with how this file is maintained at the moment? I do not believe so, therefore I'm in favor of closing this issue as already resolved. > I demand that the membership not to be enforced to be visible. Membership is visible no matter what : as soon as one authored anything (reaction, comment, issue, commit, PR), one is visible. The list, as abovementioned, is about transparency.
Author
Contributor
Copy link

Summary of situation:

  • Concerns
    • Protecting privacy
    • Excluding people without Codeberg accounts
  • I made changes to the decision-making guide, and now having a full public list isn't as important as I thought it'd be when I opened this issue
  • TEAMS.md can serve as the go-to list

So, DECISION: Not changing anything. Non-visible membership remains possible. If a trust challenge arises in the future, we can go back to this topic.

Summary of situation: - Concerns - Protecting privacy - Excluding people without Codeberg accounts - I made changes to the decision-making guide, and now having a full public list isn't as important as I thought it'd be when I opened this issue - TEAMS.md can serve as the go-to list So, DECISION: Not changing anything. Non-visible membership remains possible. If a trust challenge arises in the future, we can go back to this topic.
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
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
6 participants Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
forgejo/meta#147
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?