I do not think the security team should have a standing application form. If new members are added only when needed, and the need does not arise very often, a continually-open application form has multiple problems:

• Creates an expectation from applicants that new members are being accepted all the time, when that's not the case
• Even with appropriate messaging about whether new members are currently being accepted, creates the likelihood of applications waiting for extremely long periods (potentially years), and needing to re-check whether the applicant is still interested/applications are still current/etc. if and when a new member acceptance period does finally open up.

So this should instead define that the team will, when the team decides, open up applications for new members, but that at other times there will be no standing application/volunteer form.

Huge +1 from me. I think keeping the security team as invite-only has a lot of benefits. The noise we get from reports alone at the moment is enough - if "Can I join" is added to that it'll get unwieldy

Can you both consider the value added by allowing people from outside our typical networks to lend their support please? There are Django community members who have jobs in the security world that may be interested in helping and have beneficial and/or different skillsets that you're unlikely to invite because your circles don't overlap. My assumption here is that there's benefit in increasing the diversity of thought/background/skills. I could [easily] be wrong [in my assumption, it happens often 😁].

The logistical challenges you both present are real, but surmountable in my opinion. Though if the value isn't there, we definitely shouldn't take those challenges on.

The thing with a security team is that "larger" is not automatically "better", because more people means more difficulty coordinating and more difficulty managing access to sensitive information. And people who work in security tend to be aware of that, so will expect that the Django security team is likely to be kept on the small side and recruit when needed rather than be constantly taking in new members (in fact, I'd expect an always-open process to bring more people in to the security team would actually be seen as a red flag by a lot of people who do security professionally).

Is there some sort of specific target size that the SC/DSF Board have in mind for this team that's not coming through in this discussion? Is there some other reason why, despite getting negative feedback multiple times, this application/recruiting process keeps getting pushed in these drafts?

Is there some other reason why, despite getting negative feedback multiple times, this application/recruiting process keeps getting pushed in these drafts?

I suspect it's the history I noted above: The Security Team is one of the last places, maybe even the very last, where there is no process of open application, and the only way to get in is by invitation from an existing member. I don't think @tim-schilling is trying to make the team larger, but to make it more diverse. And we do have a problem here, similar to the one we had in the old Core -- as one obvious example, the only way women ever got in the team has been as Fellows.

I don't really have solutions. But I'm not sure the balance we have now between the different requirements is the right one.

Is there some sort of specific target size that the SC/DSF Board have in mind for this team that's not coming through in this discussion?

No, there isn't.

Is there some other reason why, despite getting negative feedback multiple times, this application/recruiting process keeps getting pushed in these drafts?

Besides the reasons outlined in the description of the PR, no.

This (and other items in this proposal) are the distilled processing of direct requests from the Fellows. While the Fellows are responsible for "Monitoring security reports and ensuring security issues are acknowledged and responded to promptly" (see call for applicants), we still need help and a supporting Security Team.

I understand that an ever-growing security team does not scale, and I agree that is not the goal. For me, the goal is twofold:

1. Make the team more diverse (there have been requests around this since a few years now).
2. Ensure the team has a reasonably sized group of active members. By active I mean doing acknowledgment and triage of reports as they come. For this I think a minimum of 5 members would be ideal, and right now we have the 1.5 Fellows and some existing members who can help in bursts.

We could define a schema where, while the daily (or weekly or monthly) active members are under 5, the application form (or whichever process) is open. When we reach that sweet spot, we close it. If we find we are lacking expertise on a given topic, we may reopen with a more tailored focus, etc.

In summary, I would keep the item in place but adjust the wording to note that the application may be open or closed at times depending on the team's needs. This could be revisited monthly during the proposed team's regular calls (as mentioned in previous PR items). I would also define somewhere what an "active" member is because, while I fully value the historical capital, the Fellows need more hands-on members in the team to help with the bulk of the report management work that may not necessarily require refined security expertise until later in the process.

Just wondering: does the slack channel already exist, or is this proposed?

I guess it's a proposal then? I thought it did, but things are getting muddied in my brain.

Is there even a need for a Slack channel for the security team? For the things the team handles, the fewer places that contain the information, the better.

I think it's more important to document what the team is doing here or wants to do than to propose a change. IMO, I'd leave it to them to expand and agree on adding Slack. This was an oversight based on what other Teams/WGs are doing.

How does one join the DSF Slack? 👀 It was only recently I learned it existed. I don't think it's part of the team onboarding process.

I had no idea there was a Slack team at all.

That being said, I'd rather have us not add another communication channel, if multiple channels already exists. However, there are indeed discussions on unifying those channels.

Also, as already stated, using Slack adds another vector where security information could be exposed.

Like @MarkusH , I learned from this suggestion about the existence of a DSF Slack.

As noted, the team keeps a private repo on github. Some discussions, and patch preparations, happen there, and there is a current suggestion to move more of the formal communications into it.

I think the security team would benefit from a communication channel with better speed and responsiveness than a mailing list, such as Discord, Slack, Signal, or a similar platform. The DSF Slack feels like the most natural place for this since it is already set up and includes private channels for discussing important and sensitive matters (for example, the Code of Conduct WG discuss their matters in a private channel in the DSF Slack).

The Fellows already use their private Slack channel to discuss security issues, so Slack is not unaware of these matters. The Fellows would also benefit from having a shared, private channel with the team members for better and speedy decision making.

If we are going to be very strict about the principle that "the fewer places that contain the information, the better," we should also consider how email providers themselves could already be compromising Django security. 🤷

Using Slack or another similar platform would centralize discussion while maintaining confidentiality and speed of coordination, I'm +1 to adding such thing.

Do we need a dedicated role for this? Works without that since ... ever??

I tried answering this in the "Creating report triager role" section on the description of the PR.

I wonder if the need here isn't better expressed by "The Fellows need more support handling initial reports and we either need more security team members, or existing members to be more active, or likely a bit of both".

I'm not sure about a half-member role 🤔

I agree with Carlton and have commented along the same lines above. I would just add that the proposed Triager role was discussed and is intended as a compromise to help some existing members feel more comfortable, so that initial report tasks do not come as unexpected or extra work. Personally, I would prefer a single type of member with everyone committing to all responsibilities, but this approach perhaps may help smooth the transition...

scheduling meetings

Question: The security team doesn't have meetings at the moment. Everything we do is fairly reactive based on reports. What do you imagine these meetings containing? More strategic process improvements? What cadence do you imagine?

I think these meetings would be reactive, not regularly scheduled. Everything within this charter can be done async from what I can see, so I wouldn't expect meetings unless something new crops up that requires one.

AFAIK we never had meetings as such; and as far as reactive actions go -- I'd imagine it the triager's responsibility to make sure that reports are properly handled, at least up to the point where either the report is dismissed or a patch is ready (especially, as the common practice is to ask reporters to verify the patches -- so this still falls under "communicate with them").

So the responsibilities I see remaining open are:

• Making sure patches make it into security releases; I believe this is still part of the Fellows' job
• Renewing group membership
• ensuring that the group’s activities align with its scope and responsibilities (I'm not sure what that means)
• and the thing mentioned in the PR description, but dropped here: They also exist as the contact points for other teams.

I think it would be valuable to have some form of scheduled meetings: not for handling individual reports, but for meta-level discussions. For example, we have ongoing topics like defining a unified view of security reports (and agreeing on the tooling for it), refining our documented policies and canned responses, handling AI-generated reports, and coordinating CNA work.

For example, the Ops team's have monthly meetings and those have been quite useful for the Fellows, both to surface cross-cutting issues and to keep momentum on shared tasks.

Suggestion: How many people do you imagine wanting as explicit "Report triagers"? I realise the goal is to take the initial triage work from the Fellows, but I wonder if this could be resolved across all members, rather than needing named roles.

This is the majority of the work, so I wonder hat everyone else is doing

As many that helps the team be sustainable I imagine. How many would be needed if each person is spending 1 hour per week?

Security reports don't arrive on a predictable cadence, so I'm not sure this is a useful way to talk about the work.

Over the past three months (July-August-September 2025), I count eight members of the team who've been first to post something in response to a newly-received report. If I push it back to six months (going back to April), it's ten members out of thirteen in your list of the current roster.

Some people are more active at this than others, of course, and to some extent it's unpredictable just owing to lots of people living in different time zones and on different schedules. But if there's a need to formalize something, perhaps formalizing some sort of "on call" setup, with a schedule where people are expected to check at least once in a given time period and post the initial response if nobody else has, would be more productive, since the important thing for the security team is not having people put in a flat amount of work per week, but rather ensuring that any given report receives a first analysis within a certain time after being received.

Though I think that's something which doesn't require formal role assignments and should be worked out in the team itself so that it can be flexible.

There's two separate roles here, that this discussion conflates IMO:

• Initial assessment of reports
• Communication with reporters

While many of us have done initial assessment, I think a lot less of us have engaged with reporters -- I haven't checked methodically, but this is my sense of things, and I know that personally I'm much more likely to behave this way.

Also (as I wrote above), even when we do make the initial response, we've learned to trust the Fellows to follow up and make sure the report is resolved -- and if we want to relieve the Fellows of this burden, then I do think a Triager role is warranted.

I agree with Shai that there are two related but distinct responsibilities: acknowledging incoming reports and performing the initial internal triage. Often the same person does both, and historically this has usually been a Fellow (an ad-hoc, implicit approach so far).

Whatever structure we decide (dedicated triagers, rotating on-call, or shared across the team), the Fellows would appreciate having it documented so expectations are clear. Importantly, the Fellows have expressed need fr more support from the rest of the team (whether through general participation or assigned roles) to handle these two initial tasks more proactively. (Many thanks to Shai and Simon, who have already been notably involved in this area.)

Nit: Given the scope, experience in all of these is pretty handy, not just some.

I sort of agree, I would also include "Software performance" since a good chunk of the reports we get are about "Potential DoS on due to poor performance on ". Proposal:

Question: Why?

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

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

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

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

Question: Due to the nature of the team, keeping it reasonably small (or at least, not larger than it needs to be) is a useful feature. Should there be some kind of expectation around how active someone is on the team being a pre-cursor for keeping their place?

Should there be some kind of expectation around how active someone is on the team being a pre-cursor for keeping their place?

I agree in principle, but I think this should be something the team discusses and decides. I'm fine with that occurring here, just letting you know that I'm not the one to drive that.

I think not -- there's a couple of people who've been on the team for a very long time, and have specific expertise which is of great value even if they only join discussions about once a year.

I fully appreciate the value of long-standing members and their institutional knowledge. At the same time, from the Fellows' perspective, it would be very valuable that all/most team members participate in acknowledging incoming reports and performing the initial triage. Whether that requires a metric or something else, I'm not entirely sure (but very open to keep talking about this).

As an additional thought, if we want to consider role distinctions, one approach could be to create a title or label for members with continuity and institutional memory rather than a separate triager role. This would help make the actual active staffing more visible and support realistic planning and distribution of work, while preserving expertise and knowledge within the team.

This could be understood in two ways:

• Reviewing reports that are received via [email protected] -- but we also get reports via HackerOne, and there have been occasions where public tickets were seen and handled as security reports;
• Use the mailing list to do the reviews -- but actually, a suggestion was recently made, and gained support, to move this kind of discussion from the list to issues on the group's private Github repo.

Ah, it sounds like we may need to flesh this section out a bit further then. I will need some help with that.

Good point! In practice we do get reports through security@, HackerOne, and occasionally public tickets. Tim, I'm happy to help going thru those details.

Furthermore, not everyone on the team currently has HackerOne access or follows it, so there's an uneven and awkward split in who sees what (some people has access to both (mailing list and hackerone), some only to hackerone and some only to the mailing list). It would be useful to spell out that all team members should have access to, and share responsibility for, all sources to avoid gaps and spread the work more evenly.

AFAIK we never had meetings as such; and as far as reactive actions go -- I'd imagine it the triager's responsibility to make sure that reports are properly handled, at least up to the point where either the report is dismissed or a patch is ready (especially, as the common practice is to ask reporters to verify the patches -- so this still falls under "communicate with them").

So the responsibilities I see remaining open are:

• Making sure patches make it into security releases; I believe this is still part of the Fellows' job
• Renewing group membership
• ensuring that the group’s activities align with its scope and responsibilities (I'm not sure what that means)
• and the thing mentioned in the PR description, but dropped here: They also exist as the contact points for other teams.

There's two separate roles here, that this discussion conflates IMO:

• Initial assessment of reports
• Communication with reporters

While many of us have done initial assessment, I think a lot less of us have engaged with reporters -- I haven't checked methodically, but this is my sense of things, and I know that personally I'm much more likely to behave this way.

Also (as I wrote above), even when we do make the initial response, we've learned to trust the Fellows to follow up and make sure the report is resolved -- and if we want to relieve the Fellows of this burden, then I do think a Triager role is warranted.

Actually, historically, members were added not so much in response to the team feeling more people were needed, but when someone in the team thought some specific volunteer might be a good fit to add.

I think not -- there's a couple of people who've been on the team for a very long time, and have specific expertise which is of great value even if they only join discussions about once a year.

Is there some other reason why, despite getting negative feedback multiple times, this application/recruiting process keeps getting pushed in these drafts?

I suspect it's the history I noted above: The Security Team is one of the last places, maybe even the very last, where there is no process of open application, and the only way to get in is by invitation from an existing member. I don't think @tim-schilling is trying to make the team larger, but to make it more diverse. And we do have a problem here, similar to the one we had in the old Core -- as one obvious example, the only way women ever got in the team has been as Fellows.

I don't really have solutions. But I'm not sure the balance we have now between the different requirements is the right one.

Like @MarkusH , I learned from this suggestion about the existence of a DSF Slack.

As noted, the team keeps a private repo on github. Some discussions, and patch preparations, happen there, and there is a current suggestion to move more of the formal communications into it.

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

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.

Good point! In practice we do get reports through security@, HackerOne, and occasionally public tickets. Tim, I'm happy to help going thru those details.

Furthermore, not everyone on the team currently has HackerOne access or follows it, so there's an uneven and awkward split in who sees what (some people has access to both (mailing list and hackerone), some only to hackerone and some only to the mailing list). It would be useful to spell out that all team members should have access to, and share responsibility for, all sources to avoid gaps and spread the work more evenly.

Maybe we could separate this into two bullets, to reflect the different responsibilities (based on current experience). How about:

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

I think it would be valuable to have some form of scheduled meetings: not for handling individual reports, but for meta-level discussions. For example, we have ongoing topics like defining a unified view of security reports (and agreeing on the tooling for it), refining our documented policies and canned responses, handling AI-generated reports, and coordinating CNA work.

For example, the Ops team's have monthly meetings and those have been quite useful for the Fellows, both to surface cross-cutting issues and to keep momentum on shared tasks.

I agree with Shai that there are two related but distinct responsibilities: acknowledging incoming reports and performing the initial internal triage. Often the same person does both, and historically this has usually been a Fellow (an ad-hoc, implicit approach so far).

Whatever structure we decide (dedicated triagers, rotating on-call, or shared across the team), the Fellows would appreciate having it documented so expectations are clear. Importantly, the Fellows have expressed need fr more support from the rest of the team (whether through general participation or assigned roles) to handle these two initial tasks more proactively. (Many thanks to Shai and Simon, who have already been notably involved in this area.)

This (and other items in this proposal) are the distilled processing of direct requests from the Fellows. While the Fellows are responsible for "Monitoring security reports and ensuring security issues are acknowledged and responded to promptly" (see call for applicants), we still need help and a supporting Security Team.

I understand that an ever-growing security team does not scale, and I agree that is not the goal. For me, the goal is twofold:

1. Make the team more diverse (there have been requests around this since a few years now).
2. Ensure the team has a reasonably sized group of active members. By active I mean doing acknowledgment and triage of reports as they come. For this I think a minimum of 5 members would be ideal, and right now we have the 1.5 Fellows and some existing members who can help in bursts.

We could define a schema where, while the daily (or weekly or monthly) active members are under 5, the application form (or whichever process) is open. When we reach that sweet spot, we close it. If we find we are lacking expertise on a given topic, we may reopen with a more tailored focus, etc.

In summary, I would keep the item in place but adjust the wording to note that the application may be open or closed at times depending on the team's needs. This could be revisited monthly during the proposed team's regular calls (as mentioned in previous PR items). I would also define somewhere what an "active" member is because, while I fully value the historical capital, the Fellows need more hands-on members in the team to help with the bulk of the report management work that may not necessarily require refined security expertise until later in the process.

I would request that applicants can prove their existing involvement with Django, either via DSF membership, affiliation with an existing WG or team, or being a Django patch author, etc.

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.

I think the security team would benefit from a communication channel with better speed and responsiveness than a mailing list, such as Discord, Slack, Signal, or a similar platform. The DSF Slack feels like the most natural place for this since it is already set up and includes private channels for discussing important and sensitive matters (for example, the Code of Conduct WG discuss their matters in a private channel in the DSF Slack).

The Fellows already use their private Slack channel to discuss security issues, so Slack is not unaware of these matters. The Fellows would also benefit from having a shared, private channel with the team members for better and speedy decision making.

If we are going to be very strict about the principle that "the fewer places that contain the information, the better," we should also consider how email providers themselves could already be compromising Django security. 🤷

Using Slack or another similar platform would centralize discussion while maintaining confidentiality and speed of coordination, I'm +1 to adding such thing.