Should Django have review teams e.g. for the ORM

Django Internals
1

Hello hello :wave:
The following is an idea/proposal that requires thoughts and feedback.

Background

We currently have a few teams of volunteers in Django who contribute to the maintenance and development of the Django framework.
Most teams also have a corresponding GitHub team and therefore can be @-ed or can have reviews requested in PRs. The exceptions here are the Technical Team and the Technical advisory team.

From my experience, in practise for the Django repository two teams are requested for reviews in PRs:

  1. The review and triage team
    This team is often requested to review the PRs of fellows (as no one can approve their own PR) and, due to timezones or availability, the other fellow may not be able to review. These PRs are often either quite trivial (fixing a spelling error) or important (addressing a release blocker).
  2. The accessibity team
    They help validate that proposed changes to Django do not violate the accessibility standards we aim to uphold. This often means they will be requested for approval of UI/UX changes, especially in the Django admin. I also believe this review has been requested in recognition that the Fellowship does not hold the accessibility expertise themselves.

This has been working really well. Thank you to everyone who helps on PR reviews and triaging tickets, your input is invaluable :heart:

With the retirement of Mariusz and Carlton, the fellowship has much less contributor and Django design experience/expertise than it once had. For example, with the recent retirement of Mariusz, we have lost a lot of ORM experience.

Note: I donā€™t think we have lost Mariusz or have lost any fellow once they retire. They all do still care lots and make very valuable contributions. This is only highlighting a change of experience in those who have dedicated paid time to look after Django.

For any PR to be merged to Django we need to ensure it meets Djangoā€™s standards, is correct and that it is the ā€œright approachā€. Having the ā€˜spider senseā€™ as to whether it is the right approach requires a lot of experience and expertise and we need to lean on others in the community for this.

I believe the organisation of the accessibility team achieves this very well. When we request an approval from them

  • this recognises needed expertise and fills a gap in the knowledge/experience of the fellowship
  • the PR author knows that the PR is waiting for a review from a particular team (I prefer this from a person they can @ specifically)

This now leads to the proposal/ideaā€¦

Proposal

I believe it would be beneficial to form more teams based on areas of expertise, similar to the accessibility team.

This would help the fellows merge PRs confidently in areas that we recognise we do not have the technical expertise in.

I believe an ORM team would be useful, there are others that we can form over time.

Why an ORM team?

The ORM has a lot of big and complex PRs requiring knowledge in multiple databases.
These are often considered more major updates and are featured at the top of the release notes (rather than in the ā€˜minor featuresā€™ section).
These are example PRs:

Other notes that are a bit rambley

We already call on individuals to review PRs specifically.
We have some people in mind who can look at certain areas of Django. But explicit is better than implicit and we donā€™t know if our knowledge is complete/accurate/up-to-date. I also think it is easier for someone to step away when they know they are part of a team and we will recruit for their expertise if needed.

This leads to the documentation benefit. I believe this can help us document the expertise of individuals and where we are at risk. I feel like the current Technical Team or Technical Advisory Team could have a sentence or ā€˜tagsā€™ on what topics they are experts in, considering the history of Django and that this knowledge isnā€™t ready available for new contributors.
The ā€˜riskā€™ I refer to here, is if we rely heavily on 1 or 2 individuals, we should be concerned about how sustainable that is and actively try to develop and mentor others for these roles.

I would love to hear:

  • Whether you think this would benefit Django in the long run
  • What risks you see or why you would not agree with the idea
  • If there is another idea or alternative you think we should discuss

If this is positively received it may require a DEP and I can draft this if appropriate, but wanted to bring the discussion here to begin with.

14 Likes
2

+1 good idea.

I think we should take the opportunity to review the roles of the Technical Team and Technical Advisory Team. The latter in particular has several members that have stepped away ā‰ˆentirely. (Iā€™d propose just having one team here instead of two, unless clear roles ā€“ and membership ā€“ for both exist)

4 Likes
3

+1 good idea

The clear advantage I see to having these teams is an easier ā€˜on-rampā€™ for new contributors where it is easier to see who would be the people to chat to about a ticket/PR etc.

I wonder if the team membership could span other parts of the community (eg Trac, here, discord, Github). I am not entirely sure what would be involved to achieve this.

I also wonder if there a need for a working group to cover the area of teams, so not an ORM review team working group as that possibly seems too specific at this point in time, but perhaps a Review Team Working Group which could cover this new team and existing related teams?

3 Likes
4

Hello everyone,

I fully support the idea of creating specialized teams, especially an ORM team. With the recent departure of key contributors, itā€™s crucial to broaden our expertise base to maintain and develop Django. Iā€™m particularly interested in ORM and eager to contribute more and grow within this team. Increased diversity in skills will strengthen the resilience and innovation of our project.

Thank you for this important initiative.

Best

1 Like
5

+1 I think the outline sounds like a great idea provided that people are willing to join :+1:

You could potentially have groups specifically for other things like HTTP, Security & other areas where the old salts have valued opinions. I canā€™t remember the specifics but there was a decision made in the request/response stack where I had to dig into the old ML to find someoneā€™s golden which made everything make sense.

4 Likes
6

+1 from too! I fully share Sarahā€™s concerns and I also agree with the presented rationale and perceived gains.

Iā€™m wondering whether determining ā€˜who could conduct specialized/extra reviews in what areas and whether an expert team is neededā€™ should be managed by a working group or overseen by the steering council (Iā€™m inclined for the latter).

2 Likes
8

The T&R team is self-organising, and that works well. The SC has oversight in theory if needed, but itā€™s not been thus far, and no real reason to think it would be.

Iā€™d try to aim for something lightweight here too. Otherwise the (real) danger is that we end up with more bureaucracy than we have the team/organisation for it.

Taking ORM as the example, there are an obvious few to bootstrap it, and go from there, Iā€™d suggest. (If what you have in mind can be spelled out quickly, by all means, but we get stuck in the weeds quite oftenā€¦)

1 Like
9

I think that itā€™s a good idea to have an identified group of instead of particular contributors to spread the load, encourage context sharing, and even mentor new contributors towards eventually joining this group.

The ORM is large and includes many components (expression resolving, compilation, backend specific logic, pooling, migrations) and would likely benefit from splitting into more groups but I think that a single one at first is way better than nothing.

4 Likes
10

After a chat with @felixxm on the subject I think that we should make sure that the most active contributors on the ORM in the past years are aware of this thread so they can chime in.

There exists an informal group of contributors that do review ORM changes and they are likely to have opinions here.

In my case I only happened to stumble upon this thread because @sarahboyce surfaced it to me but otherwise I would have completely missed it.

4 Likes
11

This is the reason why I think a subgroup would be great because I know of who youā€™re talking about and I often have questions that Iā€™d ideally like everyone to at least be aware of and I know theyā€™re not always on the forum. A communication channel dedicated for that subgroup would be ace.

4 Likes
12

+1 from me too

One thing Iā€™ll note as a risk is that requiring accessibility sign off can sometimes take time because, well, thereā€™s only three of us (for now!) and weā€™re all pretty busy with things we get paid for. So I would recommend for this team that it isnā€™t necessary to get approval for any ORM work, unless itā€™s a big juicy PR. OTOH the candidates for this team are probably more active than we are as well, so maybe itā€™s moot.

I did some ORM-lite contributions in the past, and based on that, I will say, please donā€™t suggest me for the team :slight_smile:

3 Likes
13

I think that itā€™s a good idea to have an identified group of instead of particular contributors to spread the load, encourage context sharing, and even mentor new contributors towards eventually joining this group.

One thing that could help onboard new people to contributing to the ORM would be if we gingerly started adding typing, as Simon suggests here.

14

A team would be great, in the meantime ā€“ perhaps someone could get us started by writing a quick ā€œstate of the ORMā€ post for their own blog? With things like:

  1. A list of current / recent ORM contributors
  2. A list of what features or other changes those ORM contributors would be interested in

If it helps I think the last accessibility team report was a decent template for this kind of quick overview of a given subject area: Django accessibility in 2023 and beyond. So an outline like:

  • ORM in 2024
    • Django core
      • [List of PRs or tickets or big discussions]
    • ORM in the Django community
      • [List of cool talks or blog posts]
    • ORM in numbers
      • [Something quantifiable we could compare over time]
  • ORM plans for 2025
  • ORM contributors shout-out

And if thereā€™s interest Iā€™d love to re-post it for djangoproject.com as well.

1 Like
15

Iā€™m +1 on this. Iā€™m generally happy to review any ORM PR, but I donā€™t go hunting for them. If I was a member of a github team that was asked for review on these PRs, Iā€™d be a more active reviewer.

2 Likes
16
Off-topic reply to @Lily-Foote ...

In that case :sweat_smile: ā€” Iā€™m trying to drum up reviews for @fcurellaā€™s PR to add async cursor support to the ORMā€¦

AFAICS itā€™s basically fine from an async perspective, but some ORM voices saying LGTM (or not) would be amazing :star_struck:

:gift:

4 Likes
17

A big +1 from me as well.
Iā€™d love to see specialized teams for other areas of the code as well but the ORM is an obvious place to start!

1 Like