Better Simple Logo

Steering Council 6.x Thoughts

I’ve been reflecting on the Steering Council since DjangoCon US and have engaged in a number of conversations (see Credits). I started with strong opinions and all the confidence to, well, now I’m less sure. I heard a bunch of good arguments that made me question my positions. I still feel passionate about my opinions and would like to bring them to life, but I understand they may not all get done.

My focus won’t just on the code but the community behind it. After all, at the heart of Django’s success is the community.

What follows is what I would advocate for as a member of the Steering Council.

Table of contents

Steering Council

As a prelude, I recorded a video (4 minutes) explaining what I think the Steering Council could do this upcoming term. It might be worth watching that first. I’ve also included a history section that tries to highlight the major events from the BDFLs stepping down to today.

Motivation

The Steering Council has struggled to have more than five qualified candidates in the past two elections (see History). A possible reason for that is that people feel unqualified because the role is not well defined. By specifying explicit expectations, we create a well-defined role.

By defining expectations, we also bring accountability and transparency to the role. These changes make the Steering Council’s expectations similar to the expectations of the Django Software Foundation’s Board of Directors. For example, meeting monthly and publishing minutes of those meetings. By meeting with themselves, the community, and the public and publishing minutes, the role will be more transparent. Ideally, that will translate to being more approachable and more applicants in the future.

Areas of focus

What I would like to see the Steering Council focus on is the following:

  • Support the technical teams
  • Nurture future contributors
  • Advance community consensus building
  • Facilitate feature development
  • Support future technical leadership
  • Remove technical privilege

Support the technical teams

  • Meet monthly with Django Fellows
  • Meet at least once per quarter with the technical teams
    • Accessibility
    • Ops
    • Releasers
    • Security
    • Translations
    • Triage and review

During my discussions, I discovered that the Translations team isn’t actually a team. It’s probably a good idea for the community to formalize the Translations team and determine if we need more help. I think a regular check-in with the teams would be beneficial. In those, we should be asking the following:

  • Where are your points of friction?
  • Is your team able to take on new people?
  • When are people planning on taking a break?
  • What else could the team do?

I think it’s important for people to recognize that you don’t have to be involved in the same roles forever. You can move around. And perhaps more importantly, that makes space for someone else. This allows them to grow as a person, which makes Django stronger.

Nurture future contributors

  • Participate in community mentorship programs or events, such as Google Summer of Code and Djangonaut Space
  • Hosting office hours or community conversations on open-source topics

I feel like Django is doing a great job in this area, considering everyone is volunteering their time. The community has rallied around Djangonaut Space, which has consistently been producing new contributors (52 to this point). Google Summer of Code was a major success this year with four projects. And there’s even growth at the maintainer level of contributors with Carlton’s maintainer discussion group, the proposed package maintainer working group, and Django Commons.

To help the community along this trajectory, I think the Steering Council could cultivate the community to support people’s inspiration. This can be a range of things, from being the group that administrates Google Summer of Code to hosting community conversations / open spaces. These don’t have to be frequent, but having a defined cadence and schedule is important. Some ideas are:

  • What are the next steps for async?
  • Mentorship
  • Tips & tricks of [insert system of Django]
  • How to understand a new Django project?

Advance community consensus building

  • Facilitate communication between parties when consensus is lacking

This is something I’ve heard from other Django contributors. It sounds like there may be a benefit to people wearing the Steering Council hat more often during discussions to help facilitate people to compromise or at least understanding.

The other tangible idea is to have a running list of ideas that have been proposed and are pending “consensus.” I think the Forum needs the ability to support a kind way of saying a person is -1 on something other than not responding. Ideally having some reactions for varying levels of interest seems idea.

  • 🥳 (do it now!)
  • 👍 (sounds good)
  • 🤔 (needs more info)
  • ⏳ (maybe in the future)
  • 🍬 (it’s not for me, but thank you)

I suspect there may be an add-on for the forum to help us more easily communicate.

Facilitate feature development

  • Organize community-driven road maps once every major release series
  • Coordinate and support feature assignees

I really enjoyed Thibaud’s informal roadmap exercise last year. I felt like it was well organized, productive, and perhaps most importantly, inspiring. Regardless of how we define the roadmap, we need to find ways to help people do that work. Andrew Miller (nanorepublica) had come up with several that, I thought, were great:

  • Highlight issues that are aligned to main/top priorities in forum
  • Highlight progress on all features, prioritize the main ones
  • Suggest highlighting these contributors in Django News newsletter

Additionally, there should be some coordination and support of people doing the work. Mind you, coordination and support is not management. It is checking in with those involved with a feature to support, encourage, empower and sponsor them. This could be a message to each person every one to three months to check in depending on the person and project.

Support future technical leadership

  • Elect a chair and co-chair
  • Hold monthly meetings
  • Publish a monthly report summarizing team activity, and action items/plans
  • Report on the state of Django via the living document <TBD: State of Django Report>

This is an almost entirely logistical section. I’m a strong believer in the benefits of well-structured meetings and documentation. I feel like these points will help the next Steering Council do more ambitious things than what I want to do this next term.

Remove technical privilege

  • Council members are no longer allowed to order the reversion of any commit
  • Council members are no longer allowed to veto the merging of any particular piece of code into Django

The explicit privilege to veto any merge or request the reversion of a commit should be removed. What would replace it is the current process of adding features and discussing reversions. Any community member can propose a new feature or revert a change. If there’s a consensus to implement that change, it’s implemented. When consensus can’t be achieved, the Steering Council can make a final decision on the change.

If the Fellows are exhibiting problematic behavior, a complaint can be filed with the Fellowship Working Group.

Time commitments

A major concern that was raised in my discussions by others was around time commitments. I think this is a fair concern to have. I do feel that the above can be tackled by a group of five that have this as their primary open-source contribution for the duration of the term. Though people rarely only do a single type of open-source contribution.

My expectation is that if properly divided, this can be achieved in 1.5-2.5 hours per week per Steering Council member.

Other potential solutions would be to work with the DSF board to create working groups to delegate responsibilities to others or expand the Steering Council to 7 members.

Credits

Thank you to everyone who has helped me refine the particulars (and read it in DEP format). Note that their name does not imply agreement with this post.

  • Carlton Gibson
  • Jeff Triplett
  • Ken Whitesell
  • Lily Foote
  • Matthias Kestenholz
  • Natalia Bidart
  • Sarah Boyce
  • Thibaud Colas

Thank you to Drew Winstel for reviewing my nomination statement.

Thank you to the non-Django folks who helped me process my thoughts:

History