django
Add draft of security team charter.
Hi all (@django/django-security-team, @django/steering-council), here's a new draft of the Security Team charter that's available to review. There are a few changes highlighted to help us all be more effective and to help the team build for the future. I'd like to hear your opinions and concerns on what you think would work well and what won't.
The reason we're doing this with all the teams is to help the Fellows operate a bit more smoothly in our community. For other teams, it's defining a standard way to communicate with them and their expectations. That applies to the security team, but we'd like to explore dedicating people to a specific role too (see Report Triagers).
Proposed changes from existing operations:
- Creating report triager role for initial triaging of reports
- Generating an annual report
- Allowing people to self-nominate to join the security team
- Annual opt-in for members
- Creating chair and co-chair roles
Creating report triager role
The goal here is to alleviate some of the daily workload from the Fellows. The Fellows are involved in many areas of the code base on a daily basis. They have a high awareness of what's going on and can help facilitate changes much more effectively than those who contribute less frequently.
The initial triaging of security reports is something that must be done which is why the Fellows are doing it. Helping maintain our security standards is one of their directives.
However, the initial review of a security report to determine if it's likely a valid report, what components it touches, and determining who likely will want to be involved doesn't require a Fellow. It requires legwork for someone to do the communication between the relevant parties.
Keep in mind, this change isn't necessarily asking an existing member to fill this role. If someone wants to be more active on the communication front, that's great. If not, we can recruit new team members and use this to set expectations for what their involvement would focus on.
Generating an annual report
The purpose here is to help communicate with the broader community about your work and identify if other help is needed. It's possible there are security interested folks out there that would like to do the legwork to build out tooling to help the security team or security focused parts of the community. By bringing attention to it, we may be able to motivate newer contributors.
Allowing members to self-nominate
There are a few reasons why this is being suggested:
- People who may be qualified who aren't in the personal network of the team, currently aren't eligible to join
- Some people may continue to be on this team because they think there's nobody to replace them
- Having a lower barrier to entry to join should lead to more new members, fresh ideas and energy to innovate We can also change this again in the future if we find it's unhelpful or noisy. This doesn't need to be permanent, but it seems like something helpful to be explored.
Creating a chair and co-chair role
With the addition of responsibilities that are ideally outside the Fellows purview, we'd want to identify one or two people who will help facilitate these actions. They also exist as the contact points for other teams.
Other questions
- Does the team want to revise how to remove a member from the team? It currently states it requires full consensus from the other members
- Do you want to revisit the scope of responsibilities?
Thank you to @jefftriplett and @thibaudcolas for helping with the draft.
Seth Larson posted yesterday, coincidentally, about same-equivalence-class changes being proposed to the Python's Security Team-ish: https://discuss.python.org/t/pre-pep-python-security-response-team-membership-and-operations/104199/
I think for the specific problems that have been raised here, there are multiple possible solutions and it feels like there's room to discuss what the best solutions would be. If there's a need for more people on the team, that can be done without necessarily having to run an always-open application process (which has its own problems). If there's a need for some sort of rota of responders, that can be done without having to necessarily create additional formal roles.
But the thing that's really bothering me here is: this is the second round of this proposal, and after asking questions in the discussions on the pull requests the problems this proposal is meant to solve have been surfaced, but... we had to go through multiple rounds of discussion and asking questions and pushing back to get there. Twice now, we've effectively been handed a written solution and asked for feedback on it without actually knowing what the problems were it was even meant to solve, because the broader security team has not been involved in the private meetings and processes that produced these proposals.
And that's a problem, but not one that I, or other members of the security team, can fix. @tim-schilling my suggestion would be to withdraw this and start over and this time involve the security team in the process from the very beginning. Put together a statement of problems to solve and goals to achieve, and invite the team to join in coming up with solutions (and let the team raise problems/goals to add to the list, too).
I also worry that this is a symptom of a larger tendency toward non-transparency from the new SC (which these days seems to hold a lot of closed-door meetings and only publishes pretty terse bullet-point summaries of its doings), but that's an issue for another venue.
I think for the specific problems that have been raised here, there are multiple possible solutions and it feels like there's room to discuss what the best solutions would be. If there's a need for more people on the team, that can be done without necessarily having to run an always-open application process (which has its own problems). If there's a need for some sort of rota of responders, that can be done without having to necessarily create additional formal roles.
I agree that there are multiple solutions to some of the open questions and that a discussion should occur to determine what would work best for the team.
Twice now, we've effectively been handed a written solution and asked for feedback on it without actually knowing what the problems were it was even meant to solve, because the broader security team has not been involved in the private meetings and processes that produced these proposals.
Let's be clear that the first time was from a community member who was trying to be proactive and thought they were doing something helpful.
I did make an assumption that the security team wasn't going to have time to write up a charter. This was based on feedback from off-hand comments from folks. I jumped to the next step which was writing down what I thought was being done and what I saw being asked for from the Fellows. I had some others do earlier reviews to try to smooth down rough spots. If things get reworked, they get reworked. That's fine.
Regarding being handed a written solution and asked for feedback, I have tried to be clear about the state of this charter from the title "Add draft of security team charter" to the messaging, "I'd like to hear your opinions and concerns on what you think would work well and what won't." Submitting this PR was never an intention of avoiding collaboration. It was meant as a way to expedite things because I know everyone involved has a busy schedule.
I also worry that this is a symptom of a larger tendency toward non-transparency from the new SC (which these days seems to hold a lot of closed-door meetings and only publishes pretty terse bullet-point summaries of its doings), but that's an issue for another venue.
I agree it's an issue for another venue. Let's follow-up somewhere else please.
@tim-schilling maybe a different way of phrasing this is:
To you, it's clear what this proposal is about, what its goals are, what problems it aims to solve, why it was written. It's clear because you came into this PR with all that context already: you've been involved in the meetings and chats and processes that produced this.
But to me? It's a notification that showed up in my GitHub inbox with no context attached. So when I'm reading and commenting here I can't just review the specifics of the proposal. I also have to try to piece together the context in which it was produced, and then try to review the proposal in that context.
That is a lot more difficult to do, and that difficulty could be avoided if instead the process started with, say, a problem statement presented to the team that then gets worked into a set of solutions and written down. In that case we'd all be reviewing with full context and able to understand what's going on in the proposal and why.
@ubernostrum I see a pretty clear PR description from @tim-schilling with careful wording, lots of rationale, and back-and-forth discussions on relevant points of the proposal. Can you take any further concerns / feedback / comments about the process you have elsewhere, so we can bring the discussion here back to the specifics of the proposal? I would recommend you email [email protected] so the DSF Board can then discuss and relay your feedback as appropriate.
careful wording, lots of rationale, and back-and-forth discussions on relevant points of the proposal
Well, the PR description mentions things like (to pick one example) why self-nomination was chosen as an option for expanding the team. But it doesn't explain why there's a perceived need to immediately or continuously expand the team (as the always-open nomination form would imply). It took a bit of work to draw that out, and that's when I started getting concerned about the process.
so we can bring the discussion here back to the specifics of the proposal
In the abstract, I think the drafting of any team's charter should involve that team as early and as continuously as possible, and I'm not sure why that doesn't seem to have happened here. In the specific, regarding this particular charter, I'll reiterate that I think the best thing would be to withdraw it and come to the security team with a problem statement, let the team add any problems they think are important that they feel have been left out, and then collaborate on solutions which can be turned into a charter document.
I'll also point out that if you scroll up I've offered concrete feedback on details of this proposal, including alternatives to some of the solutions proposed by the charter, once I had worked out what problems it was trying to solve.
I would recommend you email [email protected] so the DSF Board can then discuss and relay your feedback as appropriate.
I hope people understand at this point that I have a strong preference for open-source project governance to occur in the open as much as is practical, and I'm not sure why anything that's been said here would instead need to be communicated privately or through an intermediary, especially as the feedback has been majority focused on the specific security team charter being proposed.
Also, it appears that the President of the DSF is monitoring this thread, so presumably anything you feel is appropriate to relay will be relayed to whomever you think appropriate.
Alright, I will lock this thread for now 🙂 everyone -- please take a moment to read the Django code of conduct if you haven’t lately. Feedback on process is always welcome. We have plenty of channels to do that. As DSF President I would recommend [email protected] at this point in time.