dsf-working-groups
dsf-working-groups copied to clipboard
django
Add security working group
While working on the content security policy feature I was looking to see if there was a security working group with the responsibilities proposed here. I also noticed the pull request to supersede the accessibility team to a working group, so I made the assumption that a similar change could be made for the security team. Very much open to suggestions and guidance as I'm not currently involved with other WGs or the security team.
Echoing a lot of what @RealOrangeOne said about the need to keep the security team private and invite-only.
But also expanding on that: perhaps copying a template for another WG is not the best way to go about this, given the significant differences in the security team's operations.
And even maybe take a step further back and ask whether this is necessary. What can't we do, today, that we need to do, with the "Django Security Team", that we suddenly could do if it became the "DSF Security Working Group"? I can't think of anything. And philosophically, the technical teams which are concerned with the Django codebase have, I think, tended not to become DSF WGs; DEP 10 envisioned Django's technical teams coordinating with the Technical Board/Steering Council, not with the DSF Board. Accessibility is a bit of an exception because its remit was always a lot broader than just (say) the main Django framework's repository, but the security team's focus has always been narrower in a way that I think doesn't really make sense as a DSF WG.
What can't we do, today, that we need to do, with the "Django Security Team", that we suddenly could do if it became the "DSF Security Working Group"?
The Accessibility Team wasn't redefined as a Working Group to grant it additional powers. Though it did have the nice benefit of formalizing a relationship between it and the Steering Council via a liaison. The main purpose was to define some boundaries and interfaces for people to interact with. It allows for people to know what to expect from the group and what the expectations are being a part of the group.
Perhaps this part of the PR discussion should move to #28?
I agree with @ubernostrum and @RealOrangeOne, and would go even further:
This suggestion is not a technical change, it is a substantial change in the way the security "sub organization" (to avoid using "team" or "WG") works. IMO, the current way it operates is not perfect, but very far from "broken", and I don't feel the need for a major fix.
Looking at the suggested list of duties, I see some that we currently only handle on specific request:
- Review security-related pull requests across Django projects
- Provide security guidance on Django features and APIs
- Assist with security aspects of the djangoproject.com website
and I think that's ok; I also see some we don't really handle, as a team, at all:
- Develop and maintain security-related packages in the Django ecosystem (some team members have published such packages, but as individuals, not as part of the team)
- Provide security advice to Django package maintainers when requested
- Mentor new contributors interested in Django security
- Run or support security-focused sessions in DjangoCon sprints
Notably, all of these are things which do not require the care and privacy that we hold in the current Security Team. So, a WG for these, existing alongside the Security Team, might be better. Further, AFAICT none of these require any delegation of authority from the DSF Board or the SC. It can be started in the community, with no formalities, and "upgrade" to a formal WG later, with established membership, if there's a reason.
The Accessibility Team wasn't redefined as a Working Group to grant it additional powers. Though it did have the nice benefit of formalizing a relationship between it and the Steering Council via a liaison. The main purpose was to define some boundaries and interfaces for people to interact with. It allows for people to know what to expect from the group and what the expectations are being a part of the group.
The security team already has both Fellows in it, and as much of its "work product" as possible is already publicly recorded.
So I'm still trying to figure out what concrete problem you're hoping to solve with this. I'm also a bit worried that it looks like all the feedback you've gotten so far from members of the security team has been negative but it feels like the response is to try to push this forward anyway.
Hi @django/django-security-team, please hold off on further reviews temporarily. The scope in this PR is broader than what is intended for the work coming out of #28. I'd like the opportunity for @jefftriplett and I to work with @robhudson to pare this down to the governance changes and what the security team's scope is today. #28 is not meant to be a significant change to your roles. We'll use the request a review feature from the team when it's ready for input and review.
Thank you @RealOrangeOne and @shaib for identifying specific improvements, listing out the duties that are handled and which aren't. That will be helpful in the above effort.
@ubernostrum, one of the pieces of feedback the board and the steering council have heard from the Fellows is that each team should have the following:
- A way they can be contacted
- Clear responsibilities and expectations
- Definition for how people are added to the team / join the team
- Definition for how people are re-affirmed to be on the team
I hope that clarifies what problem we're trying to solve.
Another solution to this problem was to revamp the teams structure to account for these. However, the Working Group definitions already covers all of this and only required some small tweaks to also account for teams. That's why the board and the steering council are moving in this direction.
@thibaudcolas or @robhudson can you close this PR please? I'm working on a replacement.