On Sat, Mar 14, 2020 at 5:00 AM Markus Holtermann <i...@markusholtermann.eu> wrote: > Claude has been contributing to Django for almost a decade. His roles in i18n > related matters has been a constant help to the project. Providing Claude > with commit access to github.com/django/django and giving him the MERGER role > will allow him to continue his work and maintain an up to date translation > base in the project, especially in the days leading towards a release.
Again, I need to point out this is not how DEP 10 works. The Merger role is not just a new name for "committer". If Claude is appointed a Merger, he will be forbidden to do what you are saying -- a Merger cannot push their own contributions directly into Django! DEP 10 says: "[A] Merger MUST NOT merge a Minor Change primarily authored by that Merger, unless the pull request has been approved by another Merger, by a Technical Board member, or by the Django Security Team." The reason for the Merger role is that we need people with the ability to merge pull requests when the decision-making process says it is time to merge them. Mergers have some power to use judgment on what PRs get merged, but it is not the power to judge what is or isn't a good technical change to make to Django -- it is the power to judge when something does or does not need more discussion on the public forums. Mergers are not technical leaders. Their job is to serve the community by keeping a specific part of the project -- merging pull requests according to community decision process -- flowing properly. The role of Merger is also not a reward or a way to recognize someone's past accomplishments or contributions. Honoring and recognizing and rewarding people's work is the DSF's job. We do not use "let's give him commit access" for that anymore. This is not to diminish the importance of the role, because it is important. But it is important in a very different way than the old "committer" role was, and has very different responsibilities and very limited powers. Since the vote has been asked for, I urge the Technical Board members to read DEP 10 carefully and be sure you understand what a Merger does (and what a Merger doesn't do!) as you consider your votes. Django probably should have only a very few Mergers -- DEP 10 only requires that there be three of them -- because the role of Merger is only to do very specific things to keep the project working smoothly. If the worry is about ensuring translations are brought in regularly and smoothly from Transifex, the Technical Board has authority for that that and can work with the translation team to set the process (there is a whole section in DEP 10 about interaction between different teams within the Django project, for this reason). Which might end up being "Claude initiates the pulls from Transifex" (though a process that depends on one specific person is a bad process), but that is not a justification to make someone a Merger. If the worry is about i18n code in Django itself, Claude already has the same power anyone else has to open and review and comment on pull requests, start discussions on the mailing list or forum about the best approaches, and so on. But even if he is made a Merger, he would not have the power to write code and commit it directly into Django, because that is not a power of a Merger. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg92aEfTmcMbeM6HrZGCkXqdbbJf0pSuWE8%3D7aPQd-6F1A%40mail.gmail.com.
