As suggested at https://mail.python.org/pipermail/python-committers/2015-September/003556.html, this is a draft patch for a new section in the developer guide that allows core contributors to declare our major financial interest (if any) in the core development process.

In addition to adding a paragraph suggesting new core developers consider filling in the register, I also rephrased the section regarding respecting people's time to reflect the fact that we're not all volunteers these days.

Based on the discussion in the python-committers thread, I made the disclosure of commercial interests potentially impacting Python's design & development the main aim of the register, with the creation of a public list of the core developers available for contract and consulting work as a positive side benefit.

The "Consultants and Freelance Developers" seems to cover two different aspects:
  1) list devs that are consultants or freelance developers for a living;
  2) list devs that are available and can be hired to work on short term projects;

The second aspect seems orthogonal to the rest of the section (I could be working as educator/trainer, but also be available for short term projects).

IIUC the main goal here is to disclose who are we working for (if any).  However, unless I'm misunderstanding, you also want to have a list of core developers that might be available to do paid work.  ISTM that this paid work could cover at least 3 different categories:
  1) work that won't directly benefit CPython (e.g. a company can hire me as a consultant for one of their project);
  2) work that will benefit CPython (e.g. a company can pay me to add an approved feature/bugfix to CPython);
  3) work on CPython paid by the PSF (e.g. the PSF can pay me to implement a PEP or to work on the infrastructure);

I'm not sure if this was your intention, but if it was, I would put it in a separate section.

I would object to any new requirement to disclose any information that I consider to be private or personal.

This is not a requirement though:

+CPython core contributors are encouraged, but not required, to disclose the
+means by which they fund their ability to contribute time to CPython core
+development.

I like the idea, but the phrasings "disclosure" and "financial interests" sound too negative, IMO.

Wouldn't it be better to put the emphasis on a) core devs who do this in their free time, b) core devs who would be available for hired work, and c) showing off which companies indirectly support Python via employing core devs and giving them time to do core dev work as part of their job ?

Essentially replacing "disclosure" and "financial interests" with "motivation" and "support".

See e.g. the list of supporting companies we have for infrastructure (https://www.python.org/psf/league/) as example in a different area.

> Wouldn't it be better to put the emphasis on a) core devs who do this 
> in their free time, b) core devs who would be available for hired work, 
> and c) showing off which companies indirectly support Python via 
> employing core devs and giving them time to do core dev work as part of 
> their job ?

I still think that a) and c) should be separate from b).  Core devs might be contributing in their free time (i.e. a) or as part as their job (i.e. c), and on top of this they might or might not be available for hired work (i.e. b).

> Essentially replacing "disclosure" and "financial interests" with 
> "motivation" and "support".

Agreed.  Perhaps even "affiliation" could be used, even though that doesn't imply that the affiliated company supports CPython.

Ezio's right I ended up mixing together a few different objectives here, which is an artifact of how the idea came about:

* my starting point was wanting a list of folks that already have commit access (and hence are demonstrably familiar to the core development community) that the PSF can either contract with directly for work on the toolchain (and perhaps for devoting time to the tracker patch backlog), or else refer companies to. At the moment we do this based on personal knowledge, which means there are going to be missed opportunities to make connections with folks the current Board of Directors don't know personally.

* in the ensuing discussion, I realised the "we're all volunteers here" disclaimer isn't true at the moment, and is unlikely to ever be true again, and that's something that would be good to disclose to help folks understand the sustaining engineering model that has emerged around CPython

The draft patch ended up being framed as the latter, while still covering the former, which I agree is confusing.

As a result, I like the idea of making the page title "Motivations and Affiliations" to focus on the "Why are we here?" aspect.

At the end, we can then have a section "Availability for PSF Referrals" and ask core developers that are potentially able to take on contract and freelance work to let the PSF Board know. We can then maintain that list in confidence, rather than requiring people to broadcast their availability for contract work to the entire internet.

What about those of us who would *like* to broadcast our availability? :)

What would be the rules for how to fill this up?

For example, I work for Continuum, which develops Conda and Anaconda, but I'm not paid to work on CPython (I work on Numba). However, perhaps someone might want to ask for CPython work that aligns with Continuum's interests, and then I'd obviously be in the loop for the actual work.

Antoine: think that's exactly what Nick has in mind, exposing that kind of information.

Right, I'm in a similar situation at Red Hat to the one Antoine's in at Continuum Analytics - I'm not personally part of Red Hat's Python maintenance team (I used to work on internal Engineering tools, and now work on Fedora's overall developer experience), but I do sometimes spend work time helping our Python maintainers negotiate the upstream contribution and collaboration process. I also have quite a bit of leeway when it comes to getting sidetracked on upstream activities related to CPython, distutils-sig or the PSF.

Disclosing that affiliation aims to address a few things:

* it lets other community members know that Red Hat's interests are something I'm considering in community discussions - core development isn't a purely volunteer activity for me any more (and hasn't been for a number of years)
* it lets other Red Hatters know they have at least one colleague that may be able to help them out if they need particular CPython issues looked at more closely
* it (hopefully) helps nudge other commercial organisations towards the notion of either paying commercial redistributors or hiring current core developers to address their Python support needs, rather than expecting community volunteers to support their business activities for free
* inverting that last motivation, I'm hoping to help encourage commercial redistributors and other folks with a vested interest in the long term sustainability of CPython core development to engage professionally with current core contributors, and also allow their existing staff to spend work time on *becoming* core contributors

As far as more specific guidelines go, I'm thinking it may be worth including some notes on "Why might a core contributor want to publicly disclose their affiliations?" and "Why might a core contributor want to preserve their privacy?". I'm not sure exactly what that would look like yet, but I'll come up with something for the next draft.

For the final section on availability for consulting, training, and contract work, I think David makes a good point regarding folks potentially *wanting* to broadcast their availability, so I'll draft that such that "Contact via the PSF" is an option that core contributors can choose to take up. That way folks can choose between "available for direct contact" and "available for screened PSF referrals".

I'll aim to put that next draft together this coming Sunday.

Please make it clear that any listings are optional.  No core developer is required to write anything about themselves that they don't want to make public.

I think the change in tone that MAL suggested will go a long way towards clarifying the opt-in nature of the idea - my initial draft took too much of its phrasing from contexts where disclosure is required rather than optional.

Posting an alternate draft that takes the approach MAL suggested, emphasising the personal motivation side of things.

This one doesn't attempt to pre-categories the list of contributors - instead, I'd expect us to do that based on analysis of the raw text.

The opening section also makes it clear that we're not shifting the goal posts on becoming a core contributor - the only required disclosure remains that which is needed to sign the CLA and submit the signed copy to the PSF.

I like this version a lot better then the previous draft, but am still open to suggestions for improving both the formatting and the content.

I updated the patch descriptions to indicate motives.diff is the current draft while still keeping the initial iteration available.

I'll ping python-committers again to give folks another chance to comment on the second draft, and then look to merge it into the developer guide this coming weekend (incorporating any further feedback received in the interim).

Thanks, Nick. The second version looks much better.

A few minor nits, which you may want to address:

 * Order in the section should probably be alphabetic rather than
   random time based (makes it easier to search for entries once the
   list gets longer)

 * If someone is available for paid work, should we flag this in a
   generic way or simply mention this in the descriptive text ?

 * How should contact information be added to the sections ?

After the "are especially encouraged" bullet list, I think you should add a paragraph about the motivations for that special encouragement (that you've previously articulated, such as colleagues being able to learn they have a coworker they can turn to as a resource).

Other than that it looks good to me.

The attached "Final draft" patch is the version I plan to commit tomorrow. Major differences from the previous draft:

* accepted MAL's suggestion of using alphabetical order
* as RDM suggested, explained the rationale for the cases where we encourage people to participate
* after fighting with ReST trying to get it to let me have an indented paragraph following a bulleted list, I eventually hit on the idea of using the "topic" directive to separate entries from each other without introducing an ever expanding list of TOC entries on the main page
* there are now more extensive guidelines inline in the doc as a ReST comment
* three cases of "acceptable links to include" are covered: personal sites, commercial contact details, and crowdfunding
* questions and suggestions (including for new categories of acceptable links) are explicitly directed to the python-committers list

Given the useful feedback from MAL & RDM, I'll hold off on pinging python-committers again until this initial version of the page is live.

Does anyone else want to provide an entry for me to include in the initial commit? It would be good to have a couple more initial entries to help folks generalise from the available examples.

A few comments:

1) In the "Restrictions on scope" section, you could turn "Contributor Licensing Agreement" into a link.
2) You call this a "program" in a couple of place, and I'm not sure that's the right term (to me "program" sounds like an organized effort brought forward by the PSF rather than just a self-compiled list of names).
3) I would have kept the 2 disclosure-related cases separate from the availability for paid work, but I guess practicality beats purity and the paragraph you added to clarifies the difference does a good-enough job.
4) In the "commercial contacts" bullet point, you could clarify what kind of contacts are allowed (e.g. link, email address, phone numbers, company address, etc.).
5) Several devs already have a bio page on the wiki.  Instead of repeating it here, it might be easier to just add a link to that.  This makes the list shorter and easier to read, and allows people to write as much as they want on their wiki page.
6) If the bio is moved to the wiki, a more concise table-based approach might work better.  The table can include columns for names, affiliations, availability for paid work (just a check mark), link to bio, and possibly other links.

For the version I'm committing:

- I've accepted Ezio's first 3 suggestions, and modified the text accordingly
- for the 4th point, I've changed the guideline there to be about marking the entries "Available for <activity>" rather than using the generic "Commercial contact", and given more details on why I think a link to a separate info page is a better idea than including contact details directly.

I'm not entirely sold on that being the best structure, so I hope folks that actually want to use it to link out to their consulting will suggest alternatives on python-committers if they'd like to do it differently.

For the last two points, I don't want using the wiki to be a requirement (editing the dev guide directly is a much nicer user experience), but I did suggest "Extended bio" as another optional link type. I also expect the layout to be something we revisit as additional entries are added - while OpenHub shows 52 active core contributors in the past 12 months, we don't know how many are going to choose to add entries here.

New changeset 0f0ff7d19cfc by Nick Coghlan in branch 'default':
Issue #25194: Add motivations & affiliations page
https://hg.python.org/devguide/rev/0f0ff7d19cfc

Since this is new, rather than just updating the devguide I'm posting my proposed entry here first in case there is feedback.

One think I noticed in writing this is that the page is called "motivations", but because the instructions are to write the entry in the third person, it does not seem natural to actually talk about *why* I am motivated to contribute.  This may or may not be a bug :)

That's a good point about the current "3rd party bio" instructions being counterproductive - my goal is to capture "Why do we consider core development a good use of our time?" moreso than "What have we done in the past?".

So perhaps switching back to the first person model I used in the second draft would be a better idea?

Additional feedback received off-list in response to the python-committers thread:

* the current preamble is still overly legalistic and could stand to be toned down (e.g. finding a friendlier word than "disclose" in a couple of places)

* the page doesn't really explain why it exists. There's hints of that in the "Limitations on Scope" section, but it would likely be better to have a more explicit "Goals of this page" section.

I'll draft an updated version of that and post it here.

I'm about to hop on a plane to PyCon Poland, so David, how about you just go ahead and add your entry? After some reflection, I've realised we probably don't want to be too prescriptive regarding the personal bios, and can instead let patterns & themes emerge as folks add their own entries.

Additional notes for a revised preamble:

* it may be worth linking to the OpenHub contributor page to highlight the automatically generated list of active core contributors, and the fact that this page is designed to add the Motivations & Affiliations information that can't be readily extracted from existing public data sources

* a cross-link to the Experts Index for technical interests may be useful

* given the current scope limitations, it may be worth changing to "core developers" as the terminology, since we're not capturing other forms of contribution (e.g. issue triagers and user representatives in mailing list design discussions)

> * it may be worth linking to the OpenHub contributor page to highlight the automatically generated list of active core contributors

+1 but that data is a bit outdated. Perhaps the GitHub mirror can be used as a more up-to-date data source: https://github.com/python/cpython/graphs/contributors?from=2015-01-01&to=2016-01-01&type=c

> * given the current scope limitations, it may be worth changing to "core developers" as the terminology, since we're not capturing other forms of contribution

+1

New patch attached that revises the preamble to include an explicit goals section that links out to the issue tracker stats page that demonstrates that we have a problem with a lack of core reviewer time.

Much of the rest of that section has been moved up from its former location in the "Limitations" section, but some of it is new (in particular, the paragraph specifically encouraging people to look for ways to spend work time on mentoring new contributors).

The preamble is already really long (and I'm definitely open to suggestions for making it shorter), so I *didn't* try to include an explanation of how the inequitable distribution of free time means that getting more paid involvement in core development should also help improve the diversity of the core reviewer list. The gist is that as more opportunities exist to pursue CPython development as a paid activity (even if it's only one part of a larger job), then that helps remove "has lots of spare time for volunteer software development" as a gating criterion for becoming a core reviewer.

I'll ping the folks I was talking to off list to see if they'd like to comment here, or otherwise provide feedback on the new draft.

One other note: I've only linked to OpenHub, and not GitHub, as I don't know how to get a "last 12 months" statistics link for GitHub, instead of either a fixed date range or the entire commit history.

Hmm, I have some reservations about linking to statistics. They
can really give wrong incentives for committing (and IMO this
is already happening on GitHub).

Offline feedback from GvR:

* the currently accepted term for folks with commit access is "core developer", and this page isn't the place to attempt to change that, so I've switched to that conventional terminology throughout the page
* the scope limitation to core developers now appears in the section heading in addition to the preamble text

I agree there are legitimate concerns with "commits for the sake of commits" as a metric, but it's just one link used to contrast what a page like this can provide with what automated VCS analysis can do, and reviewing and incorporating other people's patches at a general bug fixing level is actually the area where we most struggle at the moment, especially for orphan modules.

I'm going to post this updated version, and then try to encourage more folks to start filling in entries now that there's a better explanation of the page's purpose.

New changeset b360bad24805 by R David Murray in branch 'default':
#25194: add my entry to 'motivations'.
https://hg.python.org/devguide/rev/b360bad24805

New changeset 2d4907e5b51c by R David Murray in branch 'default':
#25194: Fix indentation in Nick's entry.
https://hg.python.org/devguide/rev/2d4907e5b51c

As I finalized my entry it occurred to me that in fact the PSF has expressed willingness to pay me for some contract work around the tracker, but I haven't managed to make the proposal yet.  The good news in that is that in fact I have a good bit of open source work filling my schedule right now...

Is there any reason to keep this issue open at this point?

The page is up and running, with a few folks contributing entries, so there's nothing further to be done here.