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

[jefftriplett]

While I mostly tune out unless pinged, the historical context is a mix of legal responsibility and governance oversight.

From a legal standpoint, the DSF President is an officer of the foundation. If there were ever a security incident serious enough to create legal exposure for Django or the DSF, the President would likely be involved in working with counsel and helping represent the organization.

From a governance standpoint, that access has also served as a simple canary in the coal mine, indicating that the lights are still on. The President is not part of the day-to-day security process, but can notice if reports go unanswered for an unusually long time and help ensure the right people are aware.

And to confirm, yes, the DSF President has had this access since at least Russell’s time as President, and it may predate him as well. It has been a longstanding practice rather than something newly introduced.

So the access is less about participation and more about accountability, continuity, and transparency.

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

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

[sarahboyce]

We have

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

Should we have a minimum expectation target here as well so folks applying understand the work involved. For example:

- Triage 1 report every two weeks
- Join 1 team meeting a year

I think I would also want members to communicate holidays so we are aware that they are away.

[manfre]

Joining at least 1 team meeting per year seems like a suitable check to identify those who are inactive.

I like the generic "Participate in the process..." more than "Triage 1 report".

[shaib]

In this section, dealing specifically with Triagers; and with the definition of what "Traiging" means in the lines immediately following -- I prefer @sarahboyce 's wording.

[shaib]

On the other hand, see below @nessita 's suggestion of having, instead of the Triager/Regular distinction, a Regular/Special-Expert distinction, where the Special Experts are expected to participate once a year, but Regular participation expectations are higher. FWIW, that is a much better reflection of the current team's composition (but also a reflection of how hard it is, currently, to get new members).

[nessita]

Right, I would rather we have something like this, which feels more realistic and also more aligned with the needs of the Team:

• Triage at least one report a month
• Join at least one team meeting in a 6 months period

For the "Historical/Special-Expert" role, I think we could have:

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

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

In this section, dealing specifically with Triagers; and with the definition of what "Traiging" means in the lines immediately following -- I prefer @sarahboyce 's wording.

[shaib]

On the other hand, see below @nessita 's suggestion of having, instead of the Triager/Regular distinction, a Regular/Special-Expert distinction, where the Special Experts are expected to participate once a year, but Regular participation expectations are higher. FWIW, that is a much better reflection of the current team's composition (but also a reflection of how hard it is, currently, to get new members).

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

I know is a technicality, but members of the team can't apply fixes (can not merge into the repo), nor they can release artifacts. These actions are still done by mergers and releasers, so perhaps we should include some wording that at least one of each team should be a member, and that this requirements is most commonly fulfilled by the Fellows?

[tim-schilling]

I'm happy to change the wording.

My opinion is that we should be against adding requirements about who should be on the team though. It's codified in DEP 19 (and 10) that the security team can direct a PR to be merged in. That should be sufficient.

As context, I originally interpreted this as more of helping prepare the fix and the commits to be backported. Not the actual merge and release mechanisms.

[nessita]

That makes sense, thank you. I guess where I see some confusion is that for security fixes, in most cases, there are no PRs that could be instructed to be merged, thought we could say "patches" which is more realistic. In any case, I'm happy to leave it without much detail but I would value if a minimal clarification could be added so future readers are not confused like me.

[tim-schilling]

Suggested change

	- Applying and backporting those fixes
	- Applying and backporting those fixes in coordination with Mergers and Releasers

Is this the type of minimal clarification that would help?

[nessita]

This is great, but perhaps we should also include that we have the obligation to:

• handle CVE requests sent to cna@djangoproject.com
• issue CVEs for Django and projects under the Django org (we could link to the CNA scope perhaps)

[tim-schilling]

Does the first one fall under "Reviewing security reports"? We don't need to have all the details here.

Agreed on the second. Is there a way we can capture all the CVE responsibilities in one statement? If not, we can break it up.

[nessita]

For the first one, I wanted to signal those CVE requests that are not a security report but an actual CVE number request, like the one we could get from Carlton for a CVE for daphne.

EDIT: sorry I'm being confusing. I think leaving just the second item suffices.

[tim-schilling]

Suggested change

	- Maintaining the DSF's status as a CVE Numbering Authority (CNA) and casting votes (or abstaining) in CNA elections
	- Maintaining the DSF's status as a CVE Numbering Authority (CNA) and casting votes (or abstaining) in CNA elections
	- Issue CVEs for Django and projects under the Django organization

I think this is what you're referring to

[nessita]

Right, I would rather we have something like this, which feels more realistic and also more aligned with the needs of the Team:

• Triage at least one report a month
• Join at least one team meeting in a 6 months period

For the "Historical/Special-Expert" role, I think we could have:

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

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

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

I hadn't read through the new CoC guidelines in detail (such as https://github.com/django/code-of-conduct/blob/main/enforcement-ladder.md#django-code-of-conduct---enforcement-ladder).
I think I agree point 3 should be managed by the CoC team rather than the Steering Council. I agree they have the expertise and authority in that area

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

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

(it's a little hard to discuss this in a comment thread, when it's effectively "a PR on the PR", but I'll try)

Also, any DSF member or member of a DSF working group may submit a nomination

I'd use "Additionally" instead of "Also".

New members complete a 3-month onboarding

"New members, including new Fellows, complete..."

The point about Fellows leaving does not need explication IMO.

[shaib]

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.

Nor a vote, really. With inactivity, I see two scenarios:

• The member is inactive enough to fail to reaffirm their membership, and is removed for that
• The member, while otherwise inactive, does reaffirm their membership. In that case, a friendly removal with an open invitation to return is really just another request for reaffirmation, and is likely to achieve nothing.

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

Thanks for bringing that up -- I had completely failed to account for this situation. And I completely agree.

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

Yes. Except -- on second thought, and taking @LilyFirefly 's note -- in all cases where oversight seems required (inactive-but-reaffirming members, malice, or other issues) -- the approving committee should probably be the Board, not the Steering Council.

[nessita]

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

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

[jacobtylerwalls]

I can volunteer to be co-chair. I guess we can vote on this at the May meeting.

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