Skip to content
Open
Changes from 13 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
113 changes: 113 additions & 0 deletions active/security.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,113 @@
# Security Team

The Security Team is the group of people who respond to security reports for the Django framework.

## Scope of responsibilities

The Security Team is responsible for [Django’s security policies](https://docs.djangoproject.com/en/dev/internals/security/). This includes:

- Reviewing security reports
- Evaluating and developing fixes for confirmed security issues
- Applying and backporting those fixes
Comment thread
tim-schilling marked this conversation as resolved.
Outdated
- Communicating with reporters
- Communicating with the public about security releases
- Communicating with operating-system vendors and other distributors of Django
Comment thread
tim-schilling marked this conversation as resolved.
Outdated
Comment thread
tim-schilling marked this conversation as resolved.
Outdated
- Maintaining the DSF's status as a CVE Numbering Authority (CNA) and casting votes (or abstaining) in CNA elections
Comment thread
tim-schilling marked this conversation as resolved.

## Membership
Comment thread
tim-schilling marked this conversation as resolved.

- Chair:
Comment thread
tim-schilling marked this conversation as resolved.
Outdated
- Co-Chair:
Comment thread
tim-schilling marked this conversation as resolved.
Outdated
- Report triagers:
- Steering Council Liaison (must be an active Steering Council member; may be the same as Chair/Co-Chair): Frank Wiles
- Other members:
- Adam Johnson
- Jacob Walls
- Jake Howard
- Mariusz Felisiak
- Markus Holtermann
- Michael Manfre
- Natalia Bidart
- Paul McMillan
- Sarah Boyce
- Shai Berger
- Simon Charette
Comment on lines +24 to +34
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)


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.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: Why?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resolved by 9c1f116


Every member of the team is encouraged to participate in all aspects of the team, including reviewing security reports, developing fixes and communicating with reporters. The expectations for all team members are as follows:

- Participate in the process for at least one security report a year

### Role definitions

There are specific roles that have a higher level of expectations:

- **Chair / Co-Chair:** Responsible for coordinating the group, scheduling meetings, renewing the group’s membership, and ensuring that the group’s activities align with its scope and responsibilities. The Chair and Co-Chair roles should be re-evaluated annually by the team.
Comment thread
tim-schilling marked this conversation as resolved.
Outdated
- **Report Triagers:** Acknowledge and triage initial reports and communicate with reporters.

#### Report Triager
Comment thread
tim-schilling marked this conversation as resolved.

These team members are responsible for acknowledging and triaging reports initially to determine likelihood of security concern and severity. As this is a volunteer role, the Fellows will support the triagers and when necessary, handle the initial triaging.

Every member can adopt and step back as a Report Triager as their schedule allows.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


The responsibilities of a Report Triager are as follows:
Comment thread
tim-schilling marked this conversation as resolved.

- Acknowledge report received
- Initial assessment
- Request help from team/experts if necessary
- Progress to resolution
- For valid reports, hand-off to team member to own the report
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member Author

@tim-schilling tim-schilling Apr 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ownership/responsibility is still an open issue AFAICT

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

- For invalid reports, communicate with reporter

## Future membership

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
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 😁

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

- Each year, every non-Fellow member will need to reaffirm their membership with the team
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

- A member can leave for any reason

Members can also be removed by:
Comment thread
tim-schilling marked this conversation as resolved.
Outdated

- 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
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does full consensus mean? Everyone but the affected member?

Copy link
Copy Markdown
Member Author

@tim-schilling tim-schilling Oct 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct (this wouldn't be my preference, but is what I saw from other Security team documents)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member Author

@tim-schilling tim-schilling Apr 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I pulled this from the accessibility team's requirements. https://github.com/django/dsf-working-groups/blob/main/active/accessibility.md?plain=1#L87

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I couldn't find what I thought was a security team document. It had to be the accessibility team charter since I was using that as inspiration for this one.

Copy link
Copy Markdown
Member

@shaib shaib Apr 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm with @nessita -- we don't need this; if a member of the security team is so troublesome that most (even not all) of the rest of the team want to remove them, it is better to require the involvement of the Steering Council.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After writing the above, I saw that @nessita was actually suggesting only the removal of the "full consensus" requirement. I disagree.

Copy link
Copy Markdown
Member Author

@tim-schilling tim-schilling Apr 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shaib If you're suggesting we remove this line entirely and only allow the CoC and SC to remove a member, I don't think you're in alignment with @nessita. She believes (and I agree) that a smaller group of members who agree to remove a person should be sufficient. In https://github.com/django/dsf-working-groups/pull/56/files#r3124348422 it outlines it as "A vote (50%+1) of the existing team members"

Edit: I wrote the above before I saw the edits and follow-up. Whoops! Sorry to reiterate your conclusion.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor

@sarahboyce sarahboyce Apr 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor

@LilyFirefly LilyFirefly Apr 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am. Thanks!

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resolved by 9c1f116

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Member Author

@tim-schilling tim-schilling May 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


### Membership requirements

Members should possess some knowledge in most of the following topics:

- Building Django applications
- Contributing to Django
- Web applications
- Web security
- Software security
Comment thread
tim-schilling marked this conversation as resolved.
- Software performance

## Budget

No budget is required at this time. This will be reviewed at least annually.
Any changes to the budget may be requested from the board.

## Comms

The team has discussions in the following places:

1. Formal and sensitive discussions on the mailing list: security@djangoproject.com
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

2. Informal and team discussions on the DSF Slack in the private channel `#security-team`
Comment thread
tim-schilling marked this conversation as resolved.
Outdated
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

3. Monthly video-conference meetings

Comment thread
tim-schilling marked this conversation as resolved.
Comment thread
tim-schilling marked this conversation as resolved.
## Reporting

The team has two responsibilities in regards to reporting to the Board and the Steering Council:

1. Use [Django Release Announcements thread](https://forum.djangoproject.com/t/django-release-announcements/655/96) on the Forum to report security releases
Comment thread
tim-schilling marked this conversation as resolved.
Outdated
2. An annual report summarizing the team's activity, areas of concern, considerations for the future and any other relevant topics
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.