Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add draft DEP dissolving Django core. #47

Merged
merged 7 commits into from Jun 10, 2019

Conversation

ubernostrum
Copy link
Member

@ubernostrum ubernostrum commented Sep 22, 2018

Discussion has been taking place in the django-core and dsf-members mailing lists; refer there for background.

Upon adoption of this proposal, the initial set of Mergers, and the
technical board, shall work together to design a process for selecting
future Mergers, and prior to adoption of that process, shall post it
to the django-developers mailing list for feedback and voting. The
Copy link
Member

@jarshwah jarshwah Sep 23, 2018

Choose a reason for hiding this comment

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

Is there a reason for delaying the process for merger selection until after this DEP is confirmed? I would think it'd make sense to confirm all process changes now, unless we're concerned that bikeshedding smaller decisions could impact or delay the overall DEP?

I mention this because I was specifically keen to see term limits and selection processes around the merger role, to avoid ending up in the same position we're currently in where the number of Mergers forever increases.

Choose a reason for hiding this comment

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

I agree with the goal of what you're saying, but I don't necessarily think term limits may be necessary. Does this mean we'd only allow someone to hold the position of Django Fellow for a fixed amount of time, for example? I'd prefer some form of quantifiable activity required to maintain the merger role other than passage of time, as keeping people who are actively involved in merging (and the institutional knowledge that goes with such activity!) seems valuable.

Copy link
Member Author

@ubernostrum ubernostrum Sep 23, 2018

Choose a reason for hiding this comment

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

I'm not sure I understand the question; there are no term limits for Mergers here.

Copy link
Member

@jarshwah jarshwah Sep 23, 2018

Choose a reason for hiding this comment

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

Correct - there are not. But I was specifically looking for a process that would avoid the current situation that we're in where mergers are never retired. Here's a brief example of what I would like to see:

  • The set of mergers are automatically retired after some period X (maybe in line with the technical board, where a merger role is granted for a major series release)

  • A merger CAN become a merger in the next term period

  • The number of mergers can not exceed some limit X (say, 5)

Alternatively, we could review the set of mergers after each point release. "Who is interested/not interested in serving again? If we need more numbers, who from the framework team that meets the technical requirements would be interested in serving?"

In that way, the merger team would not be unlike that of the technical board. How the elections/appointments happen I'm less concerned with, and I think that could be handled by the incoming framework team. But I think some limits should be set sooner rather than later.

Choose a reason for hiding this comment

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

I'm interested in something like that too: You're automatically out of a certain period of time. I think that would help prevent burnout, and it would help encourage more people to "try it out" for a period of time. That way you're not just "in for life". (Fellows are an exception - they're in as long as DSF is paying them)

Copy link
Member Author

@ubernostrum ubernostrum Nov 22, 2018

Choose a reason for hiding this comment

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

@jarshwah if you'd like to write up an alternative proposal, go for it -- I did this basically because "let's fix the project organization" has come up so many times on mailing lists but nobody had ever taken the step of proposing how to do it.

Copy link
Member

@jarshwah jarshwah Nov 22, 2018

Choose a reason for hiding this comment

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

I'm glad you have too. I have no interest in putting together an alternative proposal, especially if it were to only differ by some small details. I'd be happy to send a PR to amend some detail if you were interested though.

Choose a reason for hiding this comment

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

Ok, I've put together at least a rough outline for a proposal here: #50

begin.

At least one election of the technical board must occur for each major
series. If the third minor release of a major series is issued, and no
Copy link
Member

@jarshwah jarshwah Sep 23, 2018

Choose a reason for hiding this comment

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

A major series spans 27 months, give or take, is this an appropriate amount of time as a default? I recognise that the process for selecting the technical board will become more complex so that 9 months (a minor series) may be too short.

Copy link
Member

@aaugustin aaugustin Oct 7, 2018

Choose a reason for hiding this comment

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

It seems consistent with the historically low turnover of the technical board.

@nemesisdesign
Copy link

nemesisdesign commented Sep 24, 2018

I can't find the discussion regarding this on the mailing list, could you link it please?
I think adding a summary of the reasons that lead to this effort would be beneficial (eg: what is not working in the current model and what we want to achieve with the switch?).

team. Membership in this team is open to anyone who wants it, and the
business of the Framework team will be carried out in public on the
django-developers mailing list. Membership in the Framework team shall
be conferred automatically upon joining that mailing list.
Copy link
Member

@claudep claudep Sep 26, 2018

Choose a reason for hiding this comment

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

I am very opposed to such an open membership with voting rights. This is an open door to potential problems. Nowadays, I assume it should be rather easy to create fake accounts, so with a little scripting ability, it would be feasible to change voting results. Couldn't we use the DSF membership as a requirement (or at least vouching by a DSF member)?

Copy link
Member

@timgraham timgraham Sep 28, 2018

Choose a reason for hiding this comment

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

I think using the DSF membership makes sense. That would eliminate the preregistration step in each election.

Copy link
Member

@jarshwah jarshwah Sep 30, 2018

Choose a reason for hiding this comment

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

I don't think using the DSF membership list is the right choice here. It excludes a lot of people that actively participate in the development of Django. Many members within the DSF do not participate in the development of Django (the code base), as evident by many of the members comments.

If the goal is to minimise vote manipulation, then I think we should find another way to do so, or to insert protections where it's obvious that there is vote manipulation occurring.

Here are some ideas:

  • Votes only count from members that have a minimum number of comments (participation threshold)
  • Votes that have clearly been manipulated are pushed to the technical board for a decision
  • Can we use the moderation tools of the list to block accounts that have been used for vote manipulation, and moderate away the vote?

Choose a reason for hiding this comment

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

Or maybe it could be limited to people who have commits in Django?

Copy link
Member

@claudep claudep Oct 1, 2018

Choose a reason for hiding this comment

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

To be clear, I didn't propose to replace the Framework team by the DSF membership, but using the DSF membership as a requirement to be a Framework member. So if someone is actively participating in the development of Django, he shouldn't have any problem joining the DSF first.

Copy link
Member

@claudep claudep Oct 3, 2018

Choose a reason for hiding this comment

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

So to be member of the Foundation, you have to be co-opted by other members, and to be member of this Framework team with voting right on the Django code, which is still the core of Django, you could freely join. I don't follow that logic. Aren't we mixing the ability to contribute to Django with the ability to take decisions for Django?

Choose a reason for hiding this comment

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

I just noticed you mentioned vouching by a DSF member in your original post - I think that's a good compromise actually.

Copy link
Member

@aaugustin aaugustin Oct 7, 2018

Choose a reason for hiding this comment

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

There was about 1000 subscribers to django-developers last I checked (years ago). Re-enrolling all these people through a validation process isn't realistic.

In a previous comment, it was suggested to use the Technical Board as a safeguard against vote manipulation. That could lead to an interesting situation if the current Technical Board said the election of a new Technical Board was manipulated. There's a word for that: "coup" ;-)

The current proposal suggests oversight by the DSF board, which seems like a better choice, as vote manipulation would be a community concern rather than a technical concern. It mentions explicitly that the DSF board could challenge bad faith registrations — typically a bunch of people with no history of contributions to Django signing up for the mailing list around election time would fit that criterion.


This is open-source. The regulation mechanism is forking. If two groups of people want to take Django in two irreconcilable directions, the result is a fork. There isn't much we can do to prevent that besides fostering a healthy community.

If thirty people we've never heard about (or bots) show up and try to take Django into a direction that we (the set of people reading and discussing this) aren't comfortable with, I think we'll manage, one way or another. We have all the keys to everything. We'll use common sense.

That's a nicety of keeping humans in charge rather than so-called "smart contracts" :-)

Copy link
Member Author

@ubernostrum ubernostrum Oct 9, 2018

Choose a reason for hiding this comment

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

We could use the DSF membership, but we'd have to completely rearchitect DSF membership to do that. Using the set of people who've expressed interest by joining the dev list, with the DSF Board as a check on people trying to sign up tons of troll accounts to vote, seemed the simpler option there.

Copy link
Member

@shaib shaib Nov 20, 2018

Choose a reason for hiding this comment

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

In reply to: "There was about 1000 subscribers to django-developers last I checked (years ago). Re-enrolling all these people through a validation process isn't realistic."
We could automatically validate all the people who are on django-developers who are also DSF members. This would mean that anybody who wants to elect the technical board, and is a little less involved in the community, will need to ask to join (the electorate, not necessarily the DSF; and they'll need to be vouched for, of course).
Forking is painful. And I think we should consider a mechanism that doesn't invite attacks -- although the simplicity of complete openness does have its advantages.

@aaugustin
Copy link
Member

aaugustin commented Sep 28, 2018

@nemesisdesign https://groups.google.com/d/msg/dsf-members/yqnWGII63mI/LUqU-FJNAQAJ

I think dsf-members is a private group. You may not be able to view the discussion unless you're a member of the Django Software Foundation.

Fellows. The Framework team shall then work to select at least one
additional Merger, and shall at all times attempt to maintain a roster
of at least three Mergers. The Framework team shall keep in mind the
need for sufficient time-zone coverage to ensure availability of at
Copy link
Member

@timgraham timgraham Sep 28, 2018

Choose a reason for hiding this comment

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

In my opinion, "The Framework team shall keep in mind the need for sufficient time-zone coverage to ensure availability of at least one Merger during sprints at major events such as DjangoCons." isn't needed. I think that the goal of sprints shouldn't be to get a bunch of things merged, but to get tickets to "Ready for checkin" so that the patches can be more carefully reviewed after the sprint is over. Otherwise, it creates pressure on mergers which sacrifices quality.

Copy link
Sponsor Member

@adamchainz adamchainz Sep 28, 2018

Choose a reason for hiding this comment

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

Agree, there has never been a rush to merge stuff at any of the sprints I've been at and I don't think anything has suffered as a result

Copy link
Member

@jarshwah jarshwah Sep 30, 2018

Choose a reason for hiding this comment

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

What has been useful at sprints are members that have a history of contributing to the code base that can help new devs setup environments and teach how to triage issues. I don't think this should fall to the merger role, but it's something we should consider in the future for sprints. Perhaps the DSF can put a call out for "helpers" for the major sprints that can take on this role?

This comment was marked as outdated.

facto* process already in place: the role of the Merger. A Merger is a
person who merges pull requests to https://github.com/django/django/.

The set of Mergers should be small; the ideal would be between three
Copy link
Member

@timgraham timgraham Sep 28, 2018

Choose a reason for hiding this comment

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

I'm not sure there's a need to limit the number of mergers. If we have a lot of good people willing to volunteer, then why not? The rationale for limiting the number of mergers should at least be explained.

Also, there's some value in having GitHub permissions to a repository besides pushing to edit. For example, closing spam submissions, editing the pull request description, or retitling pull requests to follow the commit message format.

Copy link
Member

@jarshwah jarshwah Sep 30, 2018

Choose a reason for hiding this comment

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

Regarding github permissions, this is something Mariatta has considered for the PEP she is writing to move issues to github: https://mariatta.ca/core-sprint-2018-part-2.html

So what we can do is to invite the current bug triagers as collaborators for CPython repository, give them that write access, and add branch protection such that only Python core developers can push / commit into the active branches.

Protect the release branches to a Mergers group.

Copy link
Member

@aaugustin aaugustin Oct 7, 2018

Choose a reason for hiding this comment

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

The reason is that, without this restriction, there's a good chance we'll simply recreate the core team by giving access to GitHub to whoever had it and still wants it.

Being much more liberal in giving access to GitHub and protecting the master + release branches looks like an interesting alternative.

Copy link
Member Author

@ubernostrum ubernostrum Oct 9, 2018

Choose a reason for hiding this comment

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

What @aaugustin said -- the worry is if there's a large Merger team, it's just "Django core" with a different name. The key thing here is turning merging code into a role rather than a glamorous privilege, and moving decision-making to a much more open process.

Copy link
Member

@MarkusH MarkusH Apr 28, 2019

Choose a reason for hiding this comment

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

How is "being a merger" and thus one of a "small set" less of a "glamorous privilege" than being part of core, which is significantly bigger than the "small set"?

shall have the power to use funding of Fellow positions as a way to
make the role of Merger sustainable.

Mergers shall also have the authority to make releases of Django,
Copy link
Member

@timgraham timgraham Sep 28, 2018

Choose a reason for hiding this comment

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

I think it makes sense to keep releasers as a separate team. It's non-trivial to set up all the permissions for someone to release Django, permissions which they may never use.

This comment was marked as outdated.

team. Membership in this team is open to anyone who wants it, and the
business of the Framework team will be carried out in public on the
django-developers mailing list. Membership in the Framework team shall
be conferred automatically upon joining that mailing list.
Copy link
Member

@timgraham timgraham Sep 28, 2018

Choose a reason for hiding this comment

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

I think using the DSF membership makes sense. That would eliminate the preregistration step in each election.

course of action; they may, by majority vote, choose to retain the
Merger in that role, or to remove the Merger.

Otherwise, a Merger may only be removed by:
Copy link
Member

@timgraham timgraham Sep 28, 2018

Choose a reason for hiding this comment

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

I would think there should be some activity guideline for mergers (i.e. merging an average of x pull requests per month or something). Not necessarily a requirement since life happens, but an expectation of stewarding the privilege, especially if the group is intentionally kept very small.

My alternate proposal would be to let the mergers team manage itself. Contributors to Django apply to become a merge if they think they'll use that privilege and self-renew yearly if they're still active. Existing mergers are in the best position to evaluate new members since they're reviewing pull requests from all contributors and will have a good sense if an applicant follows Django's contributing guidelines without much guidance.

Copy link
Member

@jarshwah jarshwah Sep 30, 2018

Choose a reason for hiding this comment

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

and self-renew yearly if they're still active

This is the kind of thing I was wanting to see. It'll allow inactive members to cycle out.

Copy link
Member

@aaugustin aaugustin Oct 7, 2018

Choose a reason for hiding this comment

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

I'm in favor of self-management of each team because we haven't been very good at centralized management.

Copy link
Member

@shaib shaib Nov 20, 2018

Choose a reason for hiding this comment

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

I suggest that the rules for removing Mergers should be set together with the rules for appointing them.

@nemesisdesign
Copy link

nemesisdesign commented Sep 30, 2018

@aaugustin, I see. As someone who likes to follow the development from outside, I wanted to let you know it's not really clear why this is needed in the first place. I've seen great improvements in django in the last years and I didn't think something like this was necessary. I think making the reason for this proposals clear would help the community understand how to help out.

@frankwiles
Copy link
Member

frankwiles commented Oct 3, 2018

@nemesisdesign This change isn't intended to fix a problem with what has been developed, but specifically to help encourage more people to become involved in Django without the need for a fairly closed "core" team.

We hope that by dissolving "core" and making the process more open in general we can attract more people to become major contributors vs the current process.

draft/XXXX-dissolve-core.rst Outdated Show resolved Hide resolved
draft/XXXX-dissolve-core.rst Outdated Show resolved Hide resolved
facto* process already in place: the role of the Merger. A Merger is a
person who merges pull requests to https://github.com/django/django/.

The set of Mergers should be small; the ideal would be between three
Copy link
Member

@aaugustin aaugustin Oct 7, 2018

Choose a reason for hiding this comment

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

The reason is that, without this restriction, there's a good chance we'll simply recreate the core team by giving access to GitHub to whoever had it and still wants it.

Being much more liberal in giving access to GitHub and protecting the master + release branches looks like an interesting alternative.

* A history of technical contributions to Django. This should involve
some minimum number of merged contributions; at least five, and
probably ten, with the first merged contribution occurring at least
18 months prior to election to the technical board.
Copy link
Member

@aaugustin aaugustin Oct 7, 2018

Choose a reason for hiding this comment

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

Is it a good idea to allow people who haven't committed to Django in a very long time to be elected to the technical board? Did you consider "at least 18 months and no more than 5 years" ?

Copy link
Member Author

@ubernostrum ubernostrum Oct 9, 2018

Choose a reason for hiding this comment

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

I want people to have commits in Django at some point in the past. I don't care as much if they're still generating commits today, if they're also contributing to the progress of the framework in other ways. Someone with a contribution history who hops into technical discussions on the django-developers list, for example, should be eligible even if they haven't personally contributed any code in a while.

participation in discussions on the django-developers mailing list;
reviewing and offering feedback on pull requests in the Django
source repository; and assisting in triage and management of the
Django bug tracker.
Copy link
Member

@aaugustin aaugustin Oct 7, 2018

Choose a reason for hiding this comment

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

I think we should also recognize contributions to significant third-party packages as a qualifying criterion for the technical board. Indeed, decision made by the technical board should consider the whole technical ecosystem. The perspective of an "outsider" can be useful.

team. Membership in this team is open to anyone who wants it, and the
business of the Framework team will be carried out in public on the
django-developers mailing list. Membership in the Framework team shall
be conferred automatically upon joining that mailing list.
Copy link
Member

@aaugustin aaugustin Oct 7, 2018

Choose a reason for hiding this comment

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

There was about 1000 subscribers to django-developers last I checked (years ago). Re-enrolling all these people through a validation process isn't realistic.

In a previous comment, it was suggested to use the Technical Board as a safeguard against vote manipulation. That could lead to an interesting situation if the current Technical Board said the election of a new Technical Board was manipulated. There's a word for that: "coup" ;-)

The current proposal suggests oversight by the DSF board, which seems like a better choice, as vote manipulation would be a community concern rather than a technical concern. It mentions explicitly that the DSF board could challenge bad faith registrations — typically a bunch of people with no history of contributions to Django signing up for the mailing list around election time would fit that criterion.


This is open-source. The regulation mechanism is forking. If two groups of people want to take Django in two irreconcilable directions, the result is a fork. There isn't much we can do to prevent that besides fostering a healthy community.

If thirty people we've never heard about (or bots) show up and try to take Django into a direction that we (the set of people reading and discussing this) aren't comfortable with, I think we'll manage, one way or another. We have all the keys to everything. We'll use common sense.

That's a nicety of keeping humans in charge rather than so-called "smart contracts" :-)

team may respond and state their opinions or arguments for or against
the proposal, and their vote if they wish to make one. Votes shall be
of the form "+1" (in favor) or "-1" (not in favor). There shall be no
explicit "abstain", "0", "+0" or "-0" votes. Any member wishing to
Copy link
Member

@aaugustin aaugustin Oct 7, 2018

Choose a reason for hiding this comment

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

I'm still unsure about the reasons for prohibiting these well-known techniques for reaching consensus.

Copy link
Member Author

@ubernostrum ubernostrum Oct 9, 2018

Choose a reason for hiding this comment

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

Mostly: if we're going to vastly increase the number of people who have a vote, we need to figure out how to manage it. Setting up the process so people only vote when they actually have a strong opinion (as opposed to a bunch of +0/-0/explicit abstain votes from people who don't have strong opinions) seemed like a way to do that.

Copy link
Member

@aaugustin aaugustin Oct 10, 2018

Choose a reason for hiding this comment

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

Thanks for clarifying.

Copy link
Sponsor Member

@adamchainz adamchainz Oct 14, 2018

Choose a reason for hiding this comment

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

The "+0 / -0" votes always confused me when I started reading django-developers. I think it's a good idea to get rid of them.

Copy link
Member

@shaib shaib Nov 20, 2018

Choose a reason for hiding this comment

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

Eh, "+0" can be a concise way to express an opinion, and I will be surprised if people stop using them just because a DEP said so.
I think we should rephrase this as "In the interest of making votes with many participants manageable, votes other than '+1' and '-1' will be ignored."

Choose a reason for hiding this comment

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

+0/-0 only makes sense if there are votes that can only pass with a certain percentage of eligible voters having voted. As the voting happens on the mailing list and if you signed up you will probably read it within a week and thus be able to vote on it.

If a Merger want certain people to have a look at a proposal and vote on it there is still the option to contact them directly to ask them for their input/vote.

course of action; they may, by majority vote, choose to retain the
Merger in that role, or to remove the Merger.

Otherwise, a Merger may only be removed by:
Copy link
Member

@aaugustin aaugustin Oct 7, 2018

Choose a reason for hiding this comment

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

I'm in favor of self-management of each team because we haven't been very good at centralized management.

begin.

At least one election of the technical board must occur for each major
series. If the third minor release of a major series is issued, and no
Copy link
Member

@aaugustin aaugustin Oct 7, 2018

Choose a reason for hiding this comment

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

It seems consistent with the historically low turnover of the technical board.

draft/XXXX-dissolve-core.rst Outdated Show resolved Hide resolved
Copy link
Sponsor Member

@adamchainz adamchainz left a comment

I've been silent on this discussion but that's because overall I think it's a good idea. I am one of the more recent additions to django-core back in Nov 2016 but I feel like it's mostly been a badge than a role as I've contributed less since then. Also the only time I used my commit access to was to put my name on the core team page, I always leave PR's for our current Mergers (the Fellows) as that process works really well.

Thanks for all your work on this @ubernostrum et al

Copy link
Member

@carltongibson carltongibson left a comment

Ref "shepherd":

I'm volunteering for this role.

Hi @ubernostrum, @aaugustin. I was asked when this DEP would go through. Bar bandwidth, are there any blockers or areas which could benefit from help?

Thanks for all the effort!

shall have the power to use funding of Fellow positions as a way to
make the role of Merger sustainable.

Mergers shall also have the authority to make releases of Django,

This comment was marked as outdated.

Fellows. The Framework team shall then work to select at least one
additional Merger, and shall at all times attempt to maintain a roster
of at least three Mergers. The Framework team shall keep in mind the
need for sufficient time-zone coverage to ensure availability of at

This comment was marked as outdated.


A person may serve in the role of Releaser and Merger simultaneously.

A person who has the role of Releaser will *not* automatically be
Copy link
Member

@timgraham timgraham Nov 19, 2018

Choose a reason for hiding this comment

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

Since releasing Django requires pushing version bumps, tags, etc. to Django. I think it would simplify things to say that releasers are a subset of mergers. Or if you really want releasers who aren't mergers, then say that releasers use their push access only to release Django. I think requiring coordination among a merger and non-merger releaser adds unnecessary complexity.

Copy link
Member Author

@ubernostrum ubernostrum Nov 20, 2018

Choose a reason for hiding this comment

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

I went back and forth on this a bit, and I don't think it should be required that a Releaser is a Merger. There might be times when it requires coordination between a non-Releaser Merger and a non-Merger Releaser, but I want the flexibility to decouple the roles from each other for future-proofing purposes -- the fewer people we have to set up with permissions to push packages (especially as Django Fellows can rotate out), the better.

Copy link
Member

@shaib shaib Nov 20, 2018

Choose a reason for hiding this comment

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

This does not contradict what Tim said -- his argument is that Releasers, whether they are mergers or not, should have the commit bit in order to simplify the release process. I concur.


* Feature releases.

For these, the Mergers and Releasers shall have the prerogative to ask
Copy link
Member

@timgraham timgraham Nov 19, 2018

Choose a reason for hiding this comment

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

I think it would be helpful to explain why technical board oversight is needed here and what "determination of release readiness" looks like. IMO, the mergers are the ones following day to day development and would be in the best position to determine whether there are any blockers to the release.

For each release since 1.8, I've created a page like https://code.djangoproject.com/wiki/Version2.2Roadmap#schedule and we've always hit those dates pretty close.

IMO, the "release readiness" status is fairly obvious -- just look at the release blockers. It doesn't take a week to figure that out and meanwhile, new blockers might appear.

Copy link
Member Author

@ubernostrum ubernostrum Nov 20, 2018

Choose a reason for hiding this comment

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

The main reason behind this is the trend of ensuring no one person gets to make large decisions (even if they seem fairly obvious) about Django. Having feature releases be approved by the technical board isn't a huge burden, I think, and accomplishes the goal.

Copy link
Member

@timgraham timgraham Nov 20, 2018

Choose a reason for hiding this comment

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

I don't see release candidate and final releases as large decisions. Perhaps if you list the steps for "determination of release readiness" you can convince me that this is something that the technical board adds value by doing.

In my mind, the release that involves the most discretion is the feature freeze (alpha release). Since 1.8, I've always been able to get a consensus about how to proceed on the "status of X.Y release blockers" threads. There might be some value in detailing the responsibilities of a release manager unless you wish to eliminate that role. I think that role has also worked well for Python.

Copy link
Member

@carltongibson carltongibson Nov 20, 2018

Choose a reason for hiding this comment

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

As I read this the ...prerogative to ask... is key.

If no-one asks then Tim's story will be the one in play. 99 times in a 100 that'll happen. But maybe one-time there is a need to ask, then we have a documented policy.

Is that a fair reading?

Copy link
Member

@shaib shaib Nov 20, 2018

Choose a reason for hiding this comment

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

This seems odd, and very different from existing processes AFAIK. The last time I followed the release process closely, the release was made on a pre-determined date, provided that no blocker bugs existed. This is an objective measure and a proven process. Why change it?
As a side, "lawyerly" argument, and as noted by @timgraham , it seems that this section aims to change the role of Release Manager -- which, by definitions at the preamble, would be out of scope.

Copy link
Member Author

@ubernostrum ubernostrum Nov 22, 2018

Choose a reason for hiding this comment

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

There seemed to be a desire (from the first round of feedback) to define a "Releaser" role. I'm not super committed to doing it in this document, which is why the Releaser bits are pretty rough.

The part about asking the technical board to approve a release is mostly there to assuage fears that the more open general decision-making process could push out a really bad release, by allowing the technical board to put the brakes on and prevent it going out the door. Open to better ideas on how to do this.

concrete proposal.


Backwards Compatibility
Copy link
Member

@timgraham timgraham Nov 19, 2018

Choose a reason for hiding this comment

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

I think you could remove these N/A sections.

draft/XXXX-dissolve-core.rst Outdated Show resolved Hide resolved
draft/XXXX-dissolve-core.rst Outdated Show resolved Hide resolved
* Feature releases, at the request of the Technical Board.

* Alpha and beta releases at scheduled times to be determined by the
Framework team.
Copy link
Member

@shaib shaib Nov 20, 2018

Choose a reason for hiding this comment

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

As @timgraham points below, Alpha probably shouldn't be grouped with Beta -- it is the "anchor" of the release cycle, the other phases follow almost mechanically.

team. Membership in this team is open to anyone who wants it, and the
business of the Framework team will be carried out in public on the
django-developers mailing list. Membership in the Framework team shall
be conferred automatically upon joining that mailing list.
Copy link
Member

@shaib shaib Nov 20, 2018

Choose a reason for hiding this comment

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

In reply to: "There was about 1000 subscribers to django-developers last I checked (years ago). Re-enrolling all these people through a validation process isn't realistic."
We could automatically validate all the people who are on django-developers who are also DSF members. This would mean that anybody who wants to elect the technical board, and is a little less involved in the community, will need to ask to join (the electorate, not necessarily the DSF; and they'll need to be vouched for, of course).
Forking is painful. And I think we should consider a mechanism that doesn't invite attacks -- although the simplicity of complete openness does have its advantages.

team may respond and state their opinions or arguments for or against
the proposal, and their vote if they wish to make one. Votes shall be
of the form "+1" (in favor) or "-1" (not in favor). There shall be no
explicit "abstain", "0", "+0" or "-0" votes. Any member wishing to
Copy link
Member

@shaib shaib Nov 20, 2018

Choose a reason for hiding this comment

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

Eh, "+0" can be a concise way to express an opinion, and I will be surprised if people stop using them just because a DEP said so.
I think we should rephrase this as "In the interest of making votes with many participants manageable, votes other than '+1' and '-1' will be ignored."

draft/XXXX-dissolve-core.rst Outdated Show resolved Hide resolved
majority of the Technical Board, a call will be made for the
remaining memebers to cast their votes. They shall have until the
normal close of voting (one week from the question being put to the
Technical Board) in which to do so).
Copy link
Member

@shaib shaib Nov 20, 2018

Choose a reason for hiding this comment

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

redundant ")" in the end

* Becoming disqualified due to actions taken by the Code of Conduct
committee of the Django Software Foundation, or

* By a unanimous vote of the Technical Board.
Copy link
Member

@shaib shaib Nov 20, 2018

Choose a reason for hiding this comment

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

But if I read things correctly, a Releaser may serve on the Technical Board.

Copy link
Member Author

@ubernostrum ubernostrum Nov 22, 2018

Choose a reason for hiding this comment

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

Yeah, I still don't know exactly what I want to do with the Releaser qualifications.

In my head, I saw it as not necessarily having full commit privileges, so less of a potential conflict in having a Releaser on the technical board, but as I said in another comment the whole Releaser role is still pretty rough right now.

posted to the django-developers mailing list. The five candidates
with the highest vote totals will then become the new Framework
team Technical Board.

Copy link
Member

@shaib shaib Nov 20, 2018

Choose a reason for hiding this comment

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

Every voter gets to vote for five candidates (as we do today)?

At least one election of the Technical Board must occur for each major
series. If the final minor release of a major series is issued, and no
election has yet taken place, an election shall automatically be
triggered. The Technical Board may, at its discretion, choose to run
Copy link
Member

@shaib shaib Nov 20, 2018

Choose a reason for hiding this comment

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

"Automatically triggered" here means "it's the DSF Board's responsibility to actually set things in motion", right? Perhaps it should be phrased more explicitly.

Copy link
Member

@MarkusH MarkusH Apr 28, 2019

Choose a reason for hiding this comment

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

I don't think the DSF should trigger the vote. Why can't the technical board trigger it themselves?

other Technical Board members and the DSF Board that they did not
possess the appropriate qualifications for the Technical Board, or
they become disqualified due to actions taken by the Code of Conduct
committee of the Django Software Foundation.
Copy link
Member

@shaib shaib Nov 20, 2018

Choose a reason for hiding this comment

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

I think that if a member of the Technical Board has managed to convince all other TB members and DSF Board members that they (singular they, the first member) should be removed, we shouldn't limit the grounds for removal. I would require only unanimous agreement on the reason for removal.

associated with being able to push code to the primary Django
source-code repository, and to re-frame the ability to push code to
that repository as more of a bureaucratic role which carries with it
no special privileges or status of any sort.
Copy link
Member

@shaib shaib Nov 20, 2018

Choose a reason for hiding this comment

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

I disagree. The Mergers are not beaurocrats -- they are asked to apply skill, taste and judgment.

I would rephrase this more along the lines of "remove the prestige & status which had, in the past, been given somewhat arbitrarily, and replace them with roles which are more in line with work actually being done".

Copy link
Member Author

@ubernostrum ubernostrum Nov 21, 2018

Choose a reason for hiding this comment

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

There's a difficult line to walk here in trying to outline the role of the Merger, because the goal is literally to remove as much individual "skill, taste and judgment" as possible from the process. Otherwise we might as well just say "we're keeping everything the same, but the core team is now called the Mergers team and there are fewer of them".

In my ideal world, the Merger role would literally be "push the button when consensus is reached on django-developers to do so". I can't make that happen since requiring a formal discussion + vote on every single PR is unlikely to scale, but that's where I'm coming from.

Copy link
Member

@shaib shaib Nov 21, 2018

Choose a reason for hiding this comment

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

There is a difference between "strategic" decisions, whose place is in the mailing list, and "tactical" discussions and decisions, usually made on PRs.

If the Merger's role is just to "push the button", then the process of PR review needs to be re-engineered -- the process today assumes that whoever pushes the button takes some responsibility for the commits, and is expected to give the PR a thorough review. In what you describe, that thorough review is nobody's job, and I suspect it's hard to keep a high-quality codebase this way.

Copy link
Member Author

@ubernostrum ubernostrum Nov 21, 2018

Choose a reason for hiding this comment

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

This is why I said I have an ideal in mind, but I also know I can't actually achieve that ideal. What I can do is try to get as close as possible to it, and doing everything I can to minimize the amount of perceived prestige/status associated with the Merger role. Which is what I'm trying to do with this proposal.

Choose a reason for hiding this comment

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

Is something like "core reviewers" more appropriate here?

Copy link
Member

@charettes charettes Nov 22, 2018

Choose a reason for hiding this comment

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

I share @shaib and @claudep's feeling here. My contributions to the framework certainly helped me and other contributors get a better position because of the technical knowledge we built over time by taking part in discussions and reviewing PRs and I understand not everyone would have been able to contribute that much in the first place.

However I and many other contributors not on the "technical board", most of which are part of the "core team", still dedicate a non negligible amount of their free time to PR reviews and ticket triaging even if under the proposal that should be "fellow work". There's currently no recognition for this kind of work outside of the "core developer" status so the dissolution of the team would certainly lead to a wipe out of recognized past years contributions to the project even if a PSF-Fellowship-like emeritus role was to be created given we are still actively contributing to the project.

Mergers, for example, would not have the power to say "even though django-developers reached consensus in favor of this, I'm refusing to merge it in".

Out of curiosity, has this ever happened in the past with the current structure? Is this really a problem? I've certainly seen requests to reach out to django-developers to resolve divergence of opinions or PRs and tickets but I don't recall a refusal to merge once consensus is reached.

Copy link
Member

@jacobian jacobian Nov 22, 2018

Choose a reason for hiding this comment

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

This is a good perspective to keep in mind; thanks for sharing it @charettes @shaib @claudep.

I feel pretty comfortable speaking for @ubernostrum in saying that the intent here isn't to remove recognition from people doing good work! The problem (as I see it) is that we're currently also recognizing people for (long-)past contributions, giving them power and status that may not be appropriate any more. I'm the perfect example of this: I'm a member of Django Core, giving me status and access, but I haven't contributed to the core code in years. Frankly, I'm not sure I even could any more (not without some coaching to get back up to speed).

I think the point here is that we're trying to align who has power and status within the developer community with who's actually doing the work. I shouldn't get to wear that the Core badge indefinitely, right?

Now, recognition for past contributions is something that should exist, too -- and like James says I know some things are in play at the DSF level to work on that. But I think that's out of scope for this proposal. As I see it, this change is a great step in the right direction. It's not the last step, but the existence of future steps shouldn't prevent us from taking this one.

Copy link
Member

@claudep claudep Nov 22, 2018

Choose a reason for hiding this comment

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

Thanks @jacobian for your input.

I shouldn't get to wear that the Core badge indefinitely, right?

In fact, you don't. https://www.djangoproject.com/foundation/teams/ only lists people by effective role and you can change that page now if you find your name misplaced.

Copy link
Member

@aaugustin