Translator
On 2026-06-21 12:34, Simon Josefsson wrote:
Tianon Gravi <[email protected]> writes:
On Thu, 18 Jun 2026 at 05:32, Otto Kekäläinen <[email protected]> wrote:
I would like to improve the situation starting from the Go team, and
thus I want to propose a policy for how team memberships are granted
and revoked, what levels of access exist inside the team, what
avenues exist to contribute without formal access, and how we
encourage code reviews as a way to both onboard new members and keep
existing members involved.
Before I post a draft, I wanted to check if others here think alike
and if having a policy for team membership would be useful?
Or do people dismiss such things as excess "bureaucracy" and think
the current state of things is just fine, and worrying about
potential misuse is unfounded?
IMO any DD should even be *auto*-accepted into the team
+1
I see no reason to deny if a DD wants to help, and think we should even
encode this in the policy, something like:
"If you are a DD you should consider yourself already part of the Go
team and feel welcome to contribute considering normal Debian
policies in general and Go team policies in particular".
Beyond that, I don't have a strong opinion, beyond a belief based on my
own experience with Debian package maintainer teams is that they their
presence (with typical unclear membership and contribution rules) is
that they acts as a way to exclude people wanting to help.
I'd like to see welcoming contributor guidelines that encourage and
helps new contributors, rather than membership/accesscontrol rules that
exclude people. I think/hope this is what Otto has in mind, though, but
framing it as "access control rules" may lead people in the wrong way of
thinking.
/Simon
Hi everyone!
I decided to join the conversation because I was recently accepted into
the group. And I'm willing to help. Nileshe accepted me and increased
my privileges so I could better configure the repository. I believe that
the fact that he already knew me from other teams may have facilitated
these actions.
But, for me, it was like a hug the team gave me.
If there were restrictive rules, I believe that wouldn't have convinced
me to collaborate with the team.
Concern for new members is important, but nothing that a brief search of
the candidate's history can't solve. Criteria such as:
1. time spent on Debian,
2. participation in other groups,
3. any inappropriate conduct in other teams, and so on...
But nothing that is an obstacle to entry, just a verification element.
And depending on the result of the search, this should be reflected
in the level of privileges the person will have in their repositories.
Over time, this level may change.
For a newcomer, I've already packaged 4 packages; Two are already
on Debian and two are awaiting sponsorship.
This workflow has made me quite excited to the point that I'm willing
to help fix bugs in some packages that might need it.
My concern is whether there's already a coordinated effort for packages
that need attention, in order to avoid two people working on fixing the
same package.
In the Rust and Python team, which I participate in, there is something
like that.
As a newcomer, I'm observing the team's workflow to avoid making
mistakes.
But I'm letting you know that I'm available.
Nilson F. Silva
