Yea to be clear. I just used csv and those fields as an example. I think TOML is a better choice, and we can add whatever fields are useful.
Part of the devguide build step could be turning that into a nice human facing list (does that satisfy what Marc-Andre is looking for?). We could also have a cronjob that syncs github permissions with that list. Sent from my iPhone > On Aug 4, 2018, at 12:51 PM, Brett Cannon <br...@python.org> wrote: > > > >> On Fri, Aug 3, 2018, 21:59 Donald Stufft, <don...@stufft.io> wrote: >> >> >>> On Aug 3, 2018, at 1:52 PM, Brett Cannon <br...@python.org> wrote: >>> >>> >>> >>> On Fri, 3 Aug 2018 at 00:44 Donald Stufft <don...@stufft.io> wrote: >>>> We should probably have a single source of truth for what a core developer >>>> is, and all other systems pull from that. >>> >>> Ah, but I think there might be a terminology clash here. Using MALs >>> definition means that you can be a core developer but not have commit >>> privileges due to relinquishing those privileges at some point. So I'm not >>> sure what systems you are referring to that need to know if someone >>> historically happened to be a core developer. >> >> We have that I am aware of right now: >> >> - GitHub >> - bugs.p.o >> - python-committers >> >> And it sounds like Marc-Andre is looking to add to it: >> >> - A third party/user facing list of developers, regardless of the technical >> status of their ability to commit (e.g. even if they don’t have a GitHub >> account). >> >> >> There may be other systems that I can’t recall off the top of my head (is >> anything still in hg.python.org? I dunno). > > > For us, hg.python.org only has the b.p.o code. > >> >> As of right now, I believe the list of who a core developer is and has >> historically been somewhat adhoc based upon who has permissions to commit >> things. > > > Yep. > >> Meaning that as we transition from one system to another we “lose” the >> ability to account for people over the years. This would also make it harder >> for someone to come back, because they’d have to track down someone who knew >> they were a core developer (and let’s be honest, human memory sucks so >> sometimes you’re just not sure if someone was or wasn’t). > > > Yes, us old-timers aren't perfect. 😉 If someone couldn't remember we would > probably go into the mailing list archives. > > >> >> So I think it would probably be a good thing if we had one central location >> that answers the question of who is and isn’t a core developer, that isn’t >> tied to the ACLs of one particular system that we happen to be using today. >> Ideally these other related systems (bugs.p.o, Github, etc) are then >> modified to pull from this thing as the singular source of truth. This could >> be as simple as a CSV/tom/yaml file sitting in a repository somewhere that >> lists all of the developers, their status etc, plus scripts that will >> synchronize access from that to the relevant places. > > > It would probably sit in the devguide. The question is how to potentially > display this in a readable format? Or maybe we don't care as long as we use a > format that makes both humans and computers happy? Otherwise we would have to > add a build step to the site. (Personally I say we do it in TOML since it's > readable and can still be writable through the GitHub web UI since I am > typically the person adding new folks 😁; we can then just link to it for > people to peruse.) > >> >> So for arguments sake, it could be a CSV file with the schema: >> >> Name, Email, Active, bugs.p.o Username, GitHub username > > > I would toss into the year joined. I know over in the GitHub issue about this > topic that people also don't want to lose mentor/voucher/proposer and any > notes about why the person got their commit privileges. > >> >> And then a script that could be ran whenever that would check the >> permissions of the GitHub team for CPython, and ensure that anyone listed >> there has been added to the GitHub team (and probably anyone who isn’t, has >> been removed, to ensure that getting in this file is the _way_ you get >> access). Likewise bugs.p.o could pull from this, and Marc-Andre’s public >> facing list could as well. >> >> Of course we can get fancier than a simple file somewhere, the key thing is >> that there is a single source of truth, that isn’t tied to one particular >> service or tool that we use (unless that tool is dedicated to managing this >> list of people), because anytime we tie maintaining this list of people to >> the technical aspects of giving someone an ACL to a particular system, then >> our list is going to become outdated anytime we switch systems (and some % >> of people won’t ever make the jump to the new system). >> >>> >>> Assuming what you mean is people with commit privileges, then we have the >>> "lovely" complication of usernames being inconsistent for people across >>> systems which is probably what is required to make any centralized list >>> useful for systems to interact with. We could solve this by using a table >>> instead of a list for people to list e.g. their GitHub and b.p.o usernames >>> if people wanted to go that route. >>> >>>> >>>> > On Aug 3, 2018, at 3:43 AM, M.-A. Lemburg <m...@egenix.com> wrote: >>>> > >>>> > Please note that the motivation for having a list similar to the >>>> > one we have for PSF Fellows is not to determine voting eligibility. >>>> > >>>> > This is about having a record of the core developer status available >>>> > to show to 3rd parties, e.g. to (potential) employers, organizations, >>>> > government agencies, etc. >>>> > >>>> > Having a place to also record the email addresses for internal >>>> > use such a voting or sending messages to the whole group >>>> > is a good idea nonetheless. This mailing list will likely already >>>> > serve that purpose. >>>> > >>>> > >>>> > On 02.08.2018 23:25, Brett Cannon wrote: >>>> >> On Thu, 2 Aug 2018 at 04:54 Stefan Richthofer >>>> >> <stefan.richtho...@gmail.com> >>>> >> wrote: >>>> >> >>>> >>> Again, this was in the (poorly conveyed) context of getting email >>>> >>>> addresses for them, or at least being able to contact them. >>>> >>>> >>>> >>> >>>> >>> I always thought there were already at least three places containing >>>> >>> the >>>> >>> necessary email addresses. >>>> >>> >>>> >>> * python-committers should be exactly this mailing list. >>>> >>> >>>> >> >>>> >> The list also has email archiving services as well as duplicate emails >>>> >> for >>>> >> people (e.g. I'm in it twice so that if I accidentally send an email >>>> >> from a >>>> >> personal email address it doesn't get held up in moderation). >>>> >> >>>> >> >>>> >>> * according to https://devguide.python.org/coredev/#issue-tracker it is >>>> >>> mandatory for core developers to subscribe to the issue tracker which >>>> >>> AFAIK >>>> >>> requires a confirmed email address. >>>> >>> >>>> >> * Every committer clearly must have signed the contributor agreement >>>> >>> https://www.python.org/psf/contrib/contrib-form/ which also contains a >>>> >>> mandatory email field >>>> >>> >>>> >>> So why is it still necessary to get email addresses at all? >>>> >>> >>>> >> >>>> >> Because none of those necessarily have accurate email addresses at this >>>> >> point. E.g. even python-committers has had people dropped off due to too >>>> >> many email rejections. And if we hold a vote for a governance model we >>>> >> will >>>> >> need a place to send ballots. >>>> >> >>>> >> Now if the vote is open to any core developer (using MAL's definition >>>> >> of it >>>> >> being a lifetime title), then the subscription list for this mailing >>>> >> list >>>> >> is probably good enough with some manual grooming as long we are okay >>>> >> with >>>> >> long-dormant folk who predate this list not voting (which I'm personally >>>> >> fine with). But if we wanted a way to reach just people with commit >>>> >> privileges then that's a separate challenge. >>>> >> >>>> >> -Brett >>>> >> >>>> >> >>>> >>> >>>> >>> 2018-08-02 10:59 GMT+02:00 Eric V. Smith <e...@trueblade.com>: >>>> >>> >>>> >>>> On 8/2/2018 3:32 AM, M.-A. Lemburg wrote: >>>> >>>> >>>> >>>>> On 02.08.2018 03:24, Eric V. Smith wrote: >>>> >>>>> >>>> >>>>>> On 8/1/2018 8:32 PM, Mariatta Wijaya wrote: >>>> >>>>>> >>>> >>>>>>> I think it would also be a good idea to include core developers >>>> >>>>>>> of other Python implementations in such a document, in >>>> >>>>>>> separate sections, e.g. for Jython, IronPython, PyPy, >>>> >>>>>>> Stackless, etc >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> Hmm, I don't think it is should be our (CPython) responsibility to >>>> >>>>>>> keep track and maintain the list of the core devs of alternate >>>> >>>>>>> Python >>>> >>>>>>> implementations. Don't they have their own community / website? >>>> >>>>>>> They >>>> >>>>>>> have their own repo, bug tracker, governance model, and everything, >>>> >>>>>>> right? >>>> >>>>>>> >>>> >>>>>> >>>> >>>>>> Agreed. We have a hard enough time keeping track of our own core >>>> >>>>>> developers. >>>> >>>>>> >>>> >>>>> >>>> >>>>> I don't really think we have a hard time doing this. The only >>>> >>>>> problem is that we never sat down and actually properly recorded >>>> >>>>> this in one place. >>>> >>>>> >>>> >>>> >>>> >>>> I was specifically thinking of a way to stay in touch with core devs, >>>> >>>> or >>>> >>>> more specifically a way to send them email. In the past, before we >>>> >>>> moved to >>>> >>>> github, I took it upon myself to find email addresses (current or >>>> >>>> not) for >>>> >>>> all core devs, and I gave up without much success. >>>> >>>> >>>> >>>> I agree that we could probably come up with a list of names for people >>>> >>>> who have been given the "core dev" status. >>>> >>>> >>>> >>>> For our core devs, can't we just say that the CPython core devs are >>>> >>>>>> those with commit bits on the CPython repo? I realize that will >>>> >>>>>> eliminate some people who have been core developers and never moved >>>> >>>>>> to >>>> >>>>>> github, but if they bring it to our attention, we can add them >>>> >>>>>> easily >>>> >>>>>> enough. >>>> >>>>>> >>>> >>>>> As discussed before, being a core developer is a status you >>>> >>>>> gain and never lose. There is a clear difference between have >>>> >>>>> commit rights to the (current) repo and this status. >>>> >>>>> >>>> >>>> >>>> >>>> Agreed. Again, this was in the (poorly conveyed) context of getting >>>> >>>> email >>>> >>>> addresses for them, or at least being able to contact them. >>>> >>>> >>>> >>>> Eric >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> python-committers mailing list >>>> >>>> python-committers@python.org >>>> >>>> https://mail.python.org/mailman/listinfo/python-committers >>>> >>>> Code of Conduct: https://www.python.org/psf/codeofconduct/ >>>> >>>> >>>> >>> >>>> >>> _______________________________________________ >>>> >>> python-committers mailing list >>>> >>> python-committers@python.org >>>> >>> https://mail.python.org/mailman/listinfo/python-committers >>>> >>> Code of Conduct: https://www.python.org/psf/codeofconduct/ >>>> >>> >>>> >> >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> python-committers mailing list >>>> >> python-committers@python.org >>>> >> https://mail.python.org/mailman/listinfo/python-committers >>>> >> Code of Conduct: https://www.python.org/psf/codeofconduct/ >>>> >> >>>> > >>>> > -- >>>> > Marc-Andre Lemburg >>>> > eGenix.com >>>> > >>>> > Professional Python Services directly from the Experts (#1, Aug 03 2018) >>>> >>>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>>> >>>> Python Database Interfaces ... http://products.egenix.com/ >>>> >>>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ >>>> > ________________________________________________________________________ >>>> > >>>> > ::: We implement business ideas - efficiently in both time and costs ::: >>>> > >>>> > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >>>> > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >>>> > Registered at Amtsgericht Duesseldorf: HRB 46611 >>>> > http://www.egenix.com/company/contact/ >>>> > http://www.malemburg.com/ >>>> > >>>> > _______________________________________________ >>>> > python-committers mailing list >>>> > python-committers@python.org >>>> > https://mail.python.org/mailman/listinfo/python-committers >>>> > Code of Conduct: https://www.python.org/psf/codeofconduct/ >>>> >>
_______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
