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.

[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]

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]

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.

[tim-schilling]

If a person on the security team were to do something technical that would cause them to be removed from the team permanently, there'd be two parts to it. A technical review to confirm said action and then a code of conduct review to confirm it was against our CoC.

That technical review could be led by the chair of the security team (or another member). If the team doesn't want to lead it, then I would argue the Steering Council is the next most capable on paper since it's elected to shepherd the technical direction of the framework. I think board members would be capable as well, but they aren't expected to be involved in the development of the codebase.

The CoC evaluation should be done by the CoC WG and will almost certainly include work with the Board. Since members on the Security Team are extremely trusted by the community, they'll likely have access or involvements across the community. If they action is enough to warrant their removal from the team, they'll likely have other access removed as well which may require coordination from the Board. And since these members are trusted, these types of actions are usually reviewed by the Board any way. It won't happen in isolation.

In short, process-wise, this should be Security Team -> Steering Council -> CoC WG. Though actual implementation will involve coordination across several groups and won't be siloed to specific groups.

[shaib]

If a person on the security team were to do something technical that would cause them to be removed from the team permanently, that would be corruption. I've reviewed the current Code of Conduct, and I see how that can be construed to fit under the general clause "Behaving in other ways that threaten the well-being of our community", but it is very different from the interpersonal character of all the specifically listed restricted behaviors.

I strongly disagree with this widening of the scope of the CoC WG's purview.

[dryan]

I agree with this as well. The CoCWG should avoid action based purely on a technical issue. If I'm understanding the hypothetical here it would be a person putting malicious code into Django. That feels like it should be handled by the Security and Steering Council groups.

[dryan]

Just to flesh this out a bit more, I think the security team (and all working groups) should be largely self-governing while coordinating with other groups when appropriate. For the security team here's how I would handle it:

• Removing an inactive team member is an internal vote: updating the relevant membership lists is likely notice enough to the broader community.
• Removing an unruly team member: if there's any question if the behavior violates the CoC then the behavior should get reported to the CoCWG. The CoCWG would then make a decision on the violation and recommend action that would include security team membership.
• Removing a malicious team member: that feels like a Steering Council involved-issue to me. Though I wouldn't be surprised if someone putting in malicious code also violated the CoC so both groups should get involved.

[tim-schilling]

I think the current language of the charter generally fits that framework. The main difference being around the malicious team member being removed by a decision of the board instead of the steering council.

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

[tim-schilling]

See suggestion here: https://github.com/django/dsf-working-groups/pull/56/changes#r3416804974

[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

[tim-schilling]

The specific date could be extracted into an internal document for the team to use. The Steering Council has a Google doc guide of sorts that highlights the various tools and processes in it. I would expect each team to have something similar. That can be updated as needed internally to fit whatever needs the team has without going through a public PR.

[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 👍

[tim-schilling]

Hi all, it looks like we're arriving at consensus on the charter. Can folks with any last questions or concerns please share them by July 1st? If there's nothing by then, I'll advance this to the SC/Board for approval.

[shaib]

There is one needed update and one possible update, because in team meetings, we agreed to use Issues in our private GH repo to record and triage all incoming reports.

The needed one is in the Comms section (see comment). The possible one is with regard to the last truly-open issue in the charter, that of the responsibility of a Triager: we now, at least in theory, do have the means to formally record and track ownership of issues, and so can make the Triager responsibilities as firm as originally intended. I think we can also merge the PR with the Triager role description as it stands, and wait to see if GH issues actually work well for us.