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

Open
wants to merge 3 commits into
base: master
from

Conversation

@ubernostrum
Copy link
Member

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

This comment has been minimized.

@jarshwah

jarshwah Sep 23, 2018

Member

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.

This comment has been minimized.

@FlipperPA

FlipperPA Sep 23, 2018

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.

This comment has been minimized.

@ubernostrum

ubernostrum Sep 23, 2018

Member

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

This comment has been minimized.

@jarshwah

jarshwah Sep 23, 2018

Member

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.

This comment has been minimized.

@collinanderson

collinanderson Sep 24, 2018

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)

This comment has been minimized.

@ubernostrum

ubernostrum Nov 22, 2018

Member

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

This comment has been minimized.

@jarshwah

jarshwah Nov 22, 2018

Member

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.

This comment has been minimized.

@collinanderson

collinanderson Nov 23, 2018

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

This comment has been minimized.

@jarshwah

jarshwah Sep 23, 2018

Member

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.

This comment has been minimized.

@aaugustin

aaugustin Oct 7, 2018

Member

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

@nemesisdesign

This comment has been minimized.

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.

This comment has been minimized.

@claudep

claudep Sep 26, 2018

Member

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

This comment has been minimized.

@timgraham

timgraham Sep 28, 2018

Member

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

This comment has been minimized.

@jarshwah

jarshwah Sep 30, 2018

Member

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?

This comment has been minimized.

@collinanderson

collinanderson Oct 1, 2018

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

This comment has been minimized.

@claudep

claudep Oct 1, 2018

Member

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.

This comment has been minimized.

@claudep

claudep Oct 3, 2018

Member

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?

This comment has been minimized.

@Ian-Foote

Ian-Foote Oct 4, 2018

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

This comment has been minimized.

@aaugustin

aaugustin Oct 7, 2018

Member

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

This comment has been minimized.

@ubernostrum

ubernostrum Oct 9, 2018

Member

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.

This comment has been minimized.

@shaib

shaib Nov 20, 2018

Member

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

This comment has been minimized.

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

This comment has been minimized.

@timgraham

timgraham Sep 28, 2018

Member

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.

This comment has been minimized.

@adamchainz

adamchainz Sep 28, 2018

Member

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

This comment has been minimized.

@jarshwah

jarshwah Sep 30, 2018

Member

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.

@carltongibson

carltongibson Nov 14, 2018

Member

I think the reference to sprints here is a separate topic. I'm all behind improving attendance and participation as best we can but it's not about the Merger role.

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

This comment has been minimized.

@timgraham

timgraham Sep 28, 2018

Member

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.

This comment has been minimized.

@jarshwah

jarshwah Sep 30, 2018

Member

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.

This comment has been minimized.

@aaugustin

aaugustin Oct 7, 2018

Member

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.

This comment has been minimized.

@ubernostrum

ubernostrum Oct 9, 2018

Member

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.

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 has been minimized.

@timgraham

timgraham Sep 28, 2018

Member

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.

@carltongibson

carltongibson Nov 14, 2018

Member

On the assumption there are at least two Fellows I would (still) have the Fellows do the releases, for the reasons Tim cites, and that it's a bit fiddly.

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.

This comment has been minimized.

@timgraham

timgraham Sep 28, 2018

Member

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:

This comment has been minimized.

@timgraham

timgraham Sep 28, 2018

Member

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.

This comment has been minimized.

@jarshwah

jarshwah Sep 30, 2018

Member

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.

This comment has been minimized.

@aaugustin

aaugustin Oct 7, 2018

Member

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

This comment has been minimized.

@shaib

shaib Nov 20, 2018

Member

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

@nemesisdesign

This comment has been minimized.

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

This comment has been minimized.

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.

Show resolved Hide resolved draft/XXXX-dissolve-core.rst Outdated
Show resolved Hide resolved draft/XXXX-dissolve-core.rst 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

This comment has been minimized.

@aaugustin

aaugustin Oct 7, 2018

Member

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.

This comment has been minimized.

@aaugustin

aaugustin Oct 7, 2018

Member

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" ?

This comment has been minimized.

@ubernostrum

ubernostrum Oct 9, 2018

Member

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.

This comment has been minimized.

@aaugustin

aaugustin Oct 7, 2018

Member

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.

This comment has been minimized.

@aaugustin

aaugustin Oct 7, 2018

Member

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

This comment has been minimized.

@aaugustin

aaugustin Oct 7, 2018

Member

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

This comment has been minimized.

@ubernostrum

ubernostrum Oct 9, 2018

Member

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.

This comment has been minimized.

@aaugustin

aaugustin Oct 10, 2018

Member

Thanks for clarifying.

This comment has been minimized.

@adamchainz

adamchainz Oct 14, 2018

Member

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.

This comment has been minimized.

@shaib

shaib Nov 20, 2018

Member

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

This comment has been minimized.

@hvdklauw

hvdklauw Nov 22, 2018

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

This comment has been minimized.

@aaugustin

aaugustin Oct 7, 2018

Member

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

This comment has been minimized.

@aaugustin

aaugustin Oct 7, 2018

Member

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

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

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

@carltongibson
Copy link
Member

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.

@carltongibson

carltongibson Nov 14, 2018

Member

On the assumption there are at least two Fellows I would (still) have the Fellows do the releases, for the reasons Tim cites, and that it's a bit fiddly.

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.

@carltongibson

carltongibson Nov 14, 2018

Member

I think the reference to sprints here is a separate topic. I'm all behind improving attendance and participation as best we can but it's not about the Merger role.


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

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

This comment has been minimized.

@timgraham

timgraham Nov 19, 2018

Member

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.

This comment has been minimized.

@ubernostrum

ubernostrum Nov 20, 2018

Member

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.

This comment has been minimized.

@shaib

shaib Nov 20, 2018

Member

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

This comment has been minimized.

@timgraham

timgraham Nov 19, 2018

Member

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.

This comment has been minimized.

@ubernostrum

ubernostrum Nov 20, 2018

Member

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.

This comment has been minimized.

@timgraham

timgraham Nov 20, 2018

Member

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.

This comment has been minimized.

@carltongibson

carltongibson Nov 20, 2018

Member

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?

This comment has been minimized.

@shaib

shaib Nov 20, 2018

Member

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.

This comment has been minimized.

@ubernostrum

ubernostrum Nov 22, 2018

Member

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

This comment has been minimized.

@timgraham

timgraham Nov 19, 2018

Member

I think you could remove these N/A sections.

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

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

This comment has been minimized.

@shaib

shaib Nov 20, 2018

Member

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.

This comment has been minimized.

@shaib

shaib Nov 20, 2018

Member

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

This comment has been minimized.

@shaib

shaib Nov 20, 2018

Member

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

Show resolved Hide resolved draft/XXXX-dissolve-core.rst Outdated
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).

This comment has been minimized.

@shaib

shaib Nov 20, 2018

Member

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.

This comment has been minimized.

@shaib

shaib Nov 20, 2018

Member

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

This comment has been minimized.

@ubernostrum

ubernostrum Nov 22, 2018

Member

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.

This comment has been minimized.

@shaib

shaib Nov 20, 2018

Member

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

This comment has been minimized.

@shaib

shaib Nov 20, 2018

Member

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

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.

This comment has been minimized.

@shaib

shaib Nov 20, 2018

Member

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.

This comment has been minimized.

@shaib

shaib Nov 20, 2018

Member

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

This comment has been minimized.

@ubernostrum

ubernostrum Nov 21, 2018

Member

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.

This comment has been minimized.

@shaib

shaib Nov 21, 2018

Member

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.

This comment has been minimized.

@ubernostrum

ubernostrum Nov 21, 2018

Member

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.

This comment has been minimized.

@imanhodjaev

imanhodjaev Nov 21, 2018

Is something like "core reviewers" more appropriate here?

This comment has been minimized.

@charettes

charettes Nov 22, 2018

Member

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.

This comment has been minimized.

@jacobian

jacobian Nov 22, 2018

Member

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.

This comment has been minimized.

@claudep

claudep Nov 22, 2018

Member

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.

This comment has been minimized.

@aaugustin

aaugustin Nov 22, 2018

Member

This proposal isn't going to erase https://github.com/django/django/graphs/contributors, which is the actual proof.

This comment has been minimized.

@shaib

shaib Nov 24, 2018

Member

@jacobian in response to:

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.

My first comment on this thread said:

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

These two seem perfectly aligned. @ubernostrum and @aaugustin present a different approach -- IIUC, that official roles in the project should not carry with them any direct recognition (only recognition via number of commits etc). I find this approach counter-productive.

The practical implications of this difference in this document are close to nil -- but I suspect further implications will pop up as we start to discuss the procedure for elections of Mergers and as we start working, day-to-day, with the new structure. So I think we should come to an agreement, one way or another.

@imanhodjaev

This comment has been minimized.

Copy link

imanhodjaev commented Nov 21, 2018

Hi I find this discussion very interesting and important, from my personal experience I can say the following things

  1. Signing contributor agreement is not needed at all since my PR in GitHub and thus giving my consent about CLA etc.,
  2. Contribution guidelines are good but at the same time it pushes back people willing to contribute by putting a lot of requirements ahead IMO it has to be much simpler.

May be this is only my impression but any notion of bureaucratic roles makes people think twice before contributing anything.

Also if you are aiming for open community closing mailing list is a good step, on top of it may be it makes sense to keep issues in GitHub already instead of using Trac and establish Discord or Slack community like other popular projects did it really improves transparency throughout development process and makes newcomers welcomed.

Thanks.

---------------------------

Any Merger may, on their own initiative, merge any pull request other
than one authored by that Marger. Mergers will be trusted to use their

This comment has been minimized.

@hvdklauw

hvdklauw Nov 22, 2018

Suggested change Beta
than one authored by that Marger. Mergers will be trusted to use their
than one authored by that Merger. Mergers will be trusted to use their
@bukowa

This comment has been minimized.

Copy link

bukowa commented Nov 25, 2018

If Django Foundation is being funded, what are the drawbacks hiring people to do full-time job on commits and merges?

@imanhodjaev

This comment has been minimized.

Copy link

imanhodjaev commented Nov 25, 2018

If Django Foundation is being funded, what are the drawbacks hiring people to do full-time job on commits and merges?

Or even set up Patreon campaign for full time team.

@orf

This comment has been minimized.

Copy link

orf commented Dec 9, 2018

If Django Foundation is being funded, what are the drawbacks hiring people to do full-time job on commits and merges?

Or even set up Patreon campaign for full time team.

FYI, a service my work is using called Tidelift sponsors OS packages via their subscription model. Apparently there is $417 a month here the foundation could use.

@freakboy3742

This comment has been minimized.

Copy link
Member

freakboy3742 commented Dec 9, 2018

@bukowa The DSF Fellows have been paid staff of the DSF for almost 4 years, and their mandate has been specifically to review and merge patches (and do other community management work). This isn't a new idea - it's a well tested and demonstrated way to effectively manage pull requests.

@imanhodjaev @orf The DSF already has a "Patreon/Tidelift-style" mechanism for donating money, linked from the project homepage: https://www.djangoproject.com/fundraising/

And $417 a month is... not enough. The DSF needs to pay the full-time wages of at least 1 employee. $417 a month won't make a meaningful impact on that expense.

Suggestions that the DSF should "just set up a Patreon page" "use Tidelift" are well meaning, but are ultimately misguided. As I've been saying publicly for for many years, the issue isn't finding a way to take donations. It's getting people to give donations in the first place. Setting up a Stripe/Paypal page to accept donations is trivial. The harder part is getting people - and, especially, large corporations that are making a lot of money using Django - to visit that page and put in their credit card number.

@orf

This comment has been minimized.

Copy link

orf commented Dec 9, 2018

@bukowa The DSF Fellows have been paid staff of the DSF for almost 4 years, and their mandate has been specifically to review and merge patches (and do other community management work). This isn't a new idea - it's a well tested and demonstrated way to effectively manage pull requests.

@imanhodjaev @orf The DSF already has a "Patreon/Tidelift-style" mechanism for donating money, linked from the project homepage: https://www.djangoproject.com/fundraising/

And $417 a month is... not enough. The DSF needs to pay the full-time wages of at least 1 employee. $417 a month won't make a meaningful impact on that expense.

Oh, sorry, I don't think I was clear with my previous message. Tidelift is supposed to help with this issue - companies pay a subscription for support, and this gets funnelled into the foundations/developers who build the software they rely on.

Regardless: the point was not that $400-ish is enough, merely that $400 is there and available for the taking in addition to whatever else can be raised. I just wanted to point it out as I recently became aware of the service.

The game I had to play at previous jobs was being able to generate an invoice for a donation. Finance is more than willing to sign off without question on an invoice less than $500 (and anything up to $1500 was fair game with an explanation). But it needs an invoice. It could be for a "Django super premium mega plus package" for all they care.

In large corporations there are not many people with a credit card number who can go about donating to things willy nilly, especially developers. Give people some way to raise a purchase order and this becomes a lot easier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment