Add draft of security team charter.

[tim-schilling]

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.

[RealOrangeOne]

Question: Why?

[tim-schilling]

The DSF president is the Google org admin which means they have access to everything. That includes the security mailing list.

[RealOrangeOne]

Ah, I misinterpreted "has access to" as "receives emails" 👍

[tim-schilling]

I wonder if we should mention that this is a by-product of the Google org set up in the charter?

[nessita]

FYI the president does receive every email just like the Security Team do. Unclear how that changes things :-)

[nessita]

Thank you @jefftriplett for the clarifying comment. I think it would be a good idea to capture this valuable information in the charter, how about something like:

Suggested change

	Note: The DSF Board President has access to the security mailing list, but does not otherwise participate in the team’s activities. This is mentioned for the sake of transparency.
	Note: The DSF Board President has access to the security mailing list for governance oversight and legal accountability purposes. This is a longstanding practice and is mentioned for the sake of transparency.

[shaib]

Thanks @jefftriplett , that helps understand a lot. But still, the current wording, and even @nessita 's suggestion, don't explain the discrepancy between the mailing list and other team communication channels. I'm not sure it can be done very concisely, and since this is just a side note, it shouldn't get out of hand.

I tried to come up with something that's still short, and more concrete than "governance oversight and legal accountability", and failed. So I'm +0.5 on the suggestion.

[jefftriplett]

We recently adjusted the Fellow's contractual language to read... "designated reporting channels and ensure they are acknowledged and handled promptly" on the off chance that it helps to reword it.

Maybe this?

Note: The DSF Board President has access to the designated reporting channels for governance oversight and legal accountability. This is a longstanding practice, noted here for transparency.

That drops "mailing list," which is more of a designated reporting channel, vs. adopting Slack, Signal, or something else for internal communications. I think governance-wise, we just want to know that messages that are being reported/incoming are getting handled, and something is going out on the off chance that everyone quiet quits, and the rest we already outlined.

[shaib]

Yes, thank you both. I like this a lot.

[sarahboyce]

Resolved by 9c1f116

[shaib]

Would this report be another role that the Team Chair/co-Chair should take upon themselves?

[tim-schilling]

Yes, that would be very likely, though I don't think it has to be formalized. If someone else on the team wanted to produce it, I think that'd be agreeable. Though if I were wondering what the status of the report was, I'd reach out to the chair/co-chair.

[nessita]

Thank you so much @tim-schilling for putting this together. 🌟

I see a lot of the Fellows’ asks from the last 12 months being sensibly laid out in this proposal.

I added my personal thoughts as well as the Fellows POV based on what we have been discussing on an ongoing basis for several months now. Happy to continue iterating!

[nessita]

FYI the president does receive every email just like the Security Team do. Unclear how that changes things :-)

[nessita]

It's OK to start off with this but we have very very recently agreeing to leave the mailing list purely to receive reports and that team-internal conversation would happen in a report-centralized place which will likely be GH.

[shaib]

I subscribe to the later suggestion above, that we shouldn't include our tools for accepting reports in the charter.

[tim-schilling]

@shaib this is more describing how the team communicates with each other, less on how reporters communicate with the team. Teams and working groups that have an email list have listed them in this section of their charters.

[nessita]

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/

[ubernostrum]

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.

[tim-schilling]

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.

[ubernostrum]

@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.

[thibaudcolas]

@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 foundation@djangoproject.com so the DSF Board can then discuss and relay your feedback as appropriate.

[thibaudcolas]

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 foundation@djangoproject.com at this point in time.

[tim-schilling]

There was agreement [via email] amongst the team on the following aspects:

• An advisor-type set of expectations for all team members by default
• A explicit role of Responders/Triagers that will be more active on the legwork of security reports (see Natalia's "Tasks (listed, but not discussed)" from the Notes document)
• People can adopt/remove the Responders/Triagers role as they are available and interested
• Fellows both facilitate and pick up any Responders/Triagers slack on reports

I'll be working update the document today and then facilitating further discussion on the other open points.

[sarahboyce]

Thank you for the work that has been invested in this everybody ⭐

I have added a few comments to hopefully help progress. Generally happy with what is here already 👍

[shaib]

A few updates and other notes

[shaib]

So, the issue remains open: Regardless of whether it was by design or not -- do we still want it?
(personally -- as the president is not a member of @django/django-security-team nor the security-team's Slack channel, I fail to see why they should be a member of the mailing list).

[shaib]

I subscribe to the later suggestion above, that we shouldn't include our tools for accepting reports in the charter.

[nessita]

Did a whole pass and I focused on the unresolved comments. Thank you Tim! 🌟

[nessita]

Could this be a tiny bit looser and allow for the same triager to progress it?

[tim-schilling]

Suggested change

	- For valid reports, hand-off to team member to own the report
	- For valid reports, hand-off to a team member to own or retain yourself to progress

[shaib]

One important consequence of this definition, which I think should be highlighted, is that each report is to have a more-or-less formal designated owner, at each point since its first acknowledgment. This is, as far as I'm aware, not how we do things now, and keeping it real requires a more formal process of managing reports (e.g. so long as reports are actually handled on the mailing list, it's very hard to ascertain who the owner of each report is, and if all reports are actually owned).

Note, I'm not at all opposed to this -- I'm sure it would make it much easier to verify that things are not falling between cracks -- but to be effective it also requires tooling, and while such tooling has been discussed on the team, this is very much a work-in-progress.

[sarahboyce]

So, as this should be a living document, I think we should just say "Optionally engage in the progress to resolution" so that we explicitly say a triager can still help in the creation of fixes/reviewing of fixes for the reports they triaged.
Processes around ownership we can add later once we actually have a proper process and tooling to support this (of course there is an informal process that the Fellows track things).

[shaib]

I tend to agree -- but note that this takes all the teeth out of the "Responsibility" language (see https://github.com/django/dsf-working-groups/pull/56/changes#r3110503550 -- that's a resolved comment on Line 55 in the current version).

[shaib]

Ownership/responsibility is still an open issue AFAICT

[sarahboyce]

Suggested change

	- For valid reports, hand-off to team member to own the report
	- For valid reports, state reasoning/opinion and whether wish to engage further in the progress to resolution (e.g. create a PR to resolve the issue)

Perhaps something like this

[sarahboyce]

I believe I have resolved this in 9c1f116
Please make a concrete suggestions if not

[nessita]

I think this is too strong and we should remove it. May I ask where did you see this?

[nessita]

As part of our ongoing work to support the Security Team, we (the Fellows) have been thinking about how the future membership process could be improved and defined. We would like to propose the following, with the goal of keeping things practical and lightweight while making it easier to bring in new members:

Suggested change

	The team manages its own membership by invitation. If the team needs to make a call for volunteers, it will be posted on the [djangoproject.com blog](https://www.djangoproject.com/weblog/) and the [Django Forum](https://forum.djangoproject.com).
	The membership will operate as follows:
	- There is no upper limit to the team size
	- The team/WG will vote (50%+1) to approve/deny new member.
	- The team will directly vote on new Chair/Co-Chairs
	- All Django Fellows are automatically added to the Security team
	- A Django Fellow contract termination removes the person from the Security team
	- Each year, every non-Fellow member will need to reaffirm their membership with the team
	- A member can leave for any reason
	Members can also be removed by:
	- Becoming disqualified by the Code of Conduct working group
	- A vote of the Steering Council
	- The full consensus of the rest of the Security Team
	If the team needs to make a call for volunteers, it will be posted on the [djangoproject.com blog](https://www.djangoproject.com/weblog/) and the [Django Forum](https://forum.djangoproject.com). Also, any DSF member or member of a DSF working group may submit a nomination, including a self-nomination, to the team's mailing list (security@djangoproject.com).
	Nominations are discussed within the team, with a decision made at the next Security Team meeting, provided at least a two-week window has passed since the nomination was submitted. A nomination is approved when at least one existing Security Team member votes in favor and no member objects. Team members are encouraged to share their position via the mailing list before the meeting.
	New members complete a 3-month onboarding period during which all external communications (with reporters, vendors, or distributors) must be reviewed by an existing member before sending. This ensures each report is handled consistently and no valid reports are inadvertently dismissed.
	The membership will operate as follows:
	- There is no upper limit to the team size
	- All Django Fellows are automatically added to the Security Team
	- A Django Fellow contract termination removes the Fellow from the Security Team
	- Each year, every non-Fellow member will need to reaffirm their membership with the team
	- A member can leave for any reason
	Members can also be removed by:
	- Becoming disqualified by the Code of Conduct working group
	- A vote of the Steering Council
	- A vote (50%+1) of the existing team members

cc/ @sarahboyce @jacobtylerwalls

[shaib]

Just to make sure --

• the wording "Also, any DSF member or member of a DSF working group may submit a nomination, including a self-nomination" (emphasis mine) is intended to make nominations open even when we don't ask for them?
• The onboarding period is for all new members -- including new Fellows?
• Is a Fellow free to leave the Security Team while keeping the Fellow position?

As noted above, I disagree with the idea that the team should be able to kick out members without Steering Council approval.

[sarahboyce]

nominations open even when we don't ask for them?

Yes. For example, Jake Howard was recommended by Thibaud due to his Wagtail security involvement. There was no explicit call for applications. I thought Jake's onboarding and involvement has been very positive and I would like this spontaneous addition to be possible.
If there is a point we think the team shouldn't have new members, we can have a standard response and reach out to those folks again if we change that decision.

The onboarding period is for all new members -- including new Fellows?

Personally, yes (unless the new fellow was an existing team member of course). This does motivate me to say let's reduce the onboarding from 3 months to 2.

Is a Fellow free to leave the Security Team while keeping the Fellow position?

Beautiful question. I would say no. Our current contracts have security as one of the main priorities of the role. You cannot fullfill the contract without being a member. If the contract/Fellow definition changes, maybe this will change.
But a Fellow could still be expelled by the criteria above (and as a consequence the Fellowship WG should decide whether to terminate the contract).

Does that make sense to you? Do you think any of those bits should be spelled out?

[sarahboyce]

As noted above, I disagree with the idea that the team should be able to kick out members without Steering Council approval.

Trying to think about this fresh over some coffee this morning.
I think looking at this from a different angle might help here. I see three main scenarios for removal:

• Inactivity: If a member is inactive per this document’s definition, the team should be able to remove them independently, with a note of thanks and an open invitation to return. Steering Council involvement doesn’t seem necessary here, nor does unanimous agreement from the team.
• Security or malicious concerns: The team should be able to temporarily suspend access if there is a credible concern, notifying the individual and pausing access during investigation. A final decision (e.g., permanent removal) should involve the Steering Council. Temporary action should be quick. I would propose this requires at least two team members voicing a concern.
• Code of Conduct or behavioral issues: These cases are often complex and an ugly/messy business, so I am comfortable with the Steering Council (and/or CoC team) being mediators who handle the investigation and make the final decision (perhaps with a vote).

What do we think?

[LilyFirefly]

For the final point I wouldn't feel comfortable with the Steering Council holding responsibility for or leading anything Code of Conduct related. I think that should be the responsibility of the CoC team and they can request support from the Steering Council if desired.

[sarahboyce]

OK then are we happy with the suggestion above replacing Steering Council with the DSF board?

[shaib]

I am. Thanks!

[sarahboyce]

Resolved by 9c1f116

[nessita]

Sorry to chime in a bit late but given the very recent commentaries, when we think about "Security or malicious concerns" I do think this is a blunt CoC violation so in all cases other than inactivity I think the right body may be the CoC (potentially seeking support from other bodies).

@dryan What's your view?

[tim-schilling]

My initial feeling was that removing people from teams is more on the people management side of things, which feels more like the Board than the Steering Council to me.

@LilyFirefly I think the SC should be managing the technical teams where it can instead of the Board. And in fact we have been doing that a bit more with the CoC team.

[nessita]

The Slack channel is named security-private (minor FYI).

[RealOrangeOne]

Much like there's a public channel for the steering council, should there be a public one for the security team too? That way there's a single entrypoint for security-related conversations that don't necessarily need to be in the private team-only channel?

(Perhaps bikeshedding a little here).

[jacobtylerwalls]

Let's leave that out for now: every new channel causes more fragmentation.

[MarkusH]

Can we include something that states, that they're free to remain part of the team as any other member?

[tim-schilling]

I think the reason we left that off from the Ops charter was that the member could be added as community member anyway and we didn't need to legislate it. I still think that's the better way to go, but I hold that opinion less strongly now 😁

[tim-schilling]

Suggested change

	- A Django Fellow contract termination removes the person from the Security team
	- A Django Fellow contract termination removes the person from the Security team, unless they prefer to remain on the team as a community member

[jefftriplett]

Would this spell out? I'm not quite set on the second sentence, but it spells out their possible options:

A Django Fellow contract termination does not automatically determine continued Security team membership. A former Fellow may remain on the team as a community member, choose to step down, or have their continued membership considered separately.

[shaib]

I think it's good to have a default, and I think it's good that the default is removal, so that staying needs to be explicit.

[sarahboyce]

I believe this discussion became redundant by the rewrite of this section within 9c1f116 - please re-review and shout if you feel anything should be added in

[shaib]

I read that rewrite as implicitly saying that a fellow stays on the team after contract termination -- because it doesn't list contract termination as a reason for removal. I am OK with that (my comment from a month ago notwithstanding), but I think it should still be explicit.

[jacobtylerwalls]

I like Sarah's proposed clarifications.

I also like Natalia's proposal at the top of this thread. The 3 (2?) month onboarding sounds good -- I believe I took about 2 or 3 months before I started firing off replies on "my own authority" just to manage the volume.

[shaib]

While we're getting close here, there are still a couple of important issues we need to resolve. In particular,

• the issue of member removal doesn't seem to be consolidated, and
• the issue of responsibility/ownership of reports appears to be in conflict between what we might like to have and what we currently do

Other issues mentioned here are, I think, minor, or just have agreed comments that need to be applied.

[shaib]

Ownership/responsibility is still an open issue AFAICT

[shaib]

This thread requires more work as well

[RealOrangeOne]

Thought: Should there be some kind of expected tenure for the Report Triager role? My thinking being that if people are free to rotate "as schedule allows", it may not be explicit when they do, so the entire team could step back assuming the rest of the team can pick things up.

[sarahboyce]

Although I like the idea, I don't think we need to define a process here as Fellows would fill this role if we ever had a whole team step back

[RealOrangeOne]

Thought: Should this coincide with a specific date, or is it based on when they joined? It may be beneficial to have a single time this is discussed for all members, to also enable a single time when the team may be actively looking to recruit.

[sarahboyce]

I agree this should be a specific date, such as in the last team meeting of the year

[shaib]

+1

[RealOrangeOne]

Thought: As part of formalizing the charter, should we pre-seed the triagers role with those interested? Currently it looks like the team is incredibly understaffed despite that (probably) not being the case.

[sarahboyce]

I agree we should fill this but I don't think it's a requirement for merging (as we need to keep the list up-to-date anyway)

[sarahboyce]

Thank you all!
Approving as I believe this could be merged as is, I will continue to engage in discussions as and when they pop up 👍