Bikeshed: what should the domain name be of the new unified contributor's guide?

[gvanrossum]

• Our strawman was 'contrib.python.org'.
• On Discourse there was some debate suggesting that it ought to be 'contribute.python.org'.
• I could also imagine 'contributing.python.org'.
• I could also imagine 'contrib.python.org' as an alias for the full name (similar to the way that 'doc.python.org' redirects to 'docs.python.org').

[Mariatta]

Is there a lot of maintenance cost url alias/forwarding? Maybe we can make all those proposed urls work and point to the one chosen url.

[saaketp]

I could also imagine 'contributing.python.org'.

I'd vote for this, it is similar to packaging.python.org

It would be nicer if the title of the guide matches the URL.
So "Contributing Guide" if we go with contributing.python.org
That also works as filter to rule out many of the options which sound weird like "Contrib Guide" or "Contribute Guide"

[JacobCoffee]

docs.python.org/contribute or docs.python.org/contribution-guide seems like a nice option, but its longer still.

We could also do all of the above with just a small maintenance burden, but that will soon be managed via code so it isn't a huge deal IMO.

Whichever we decide if you assign me the issue on the final naming(s), I can set the DNS entries up.

[funkyfuture]

some random thoughts, not trying to argue for or against specific proposals / ideas:

• as it has been mentioned in the referenced other message board, the term contrib is canonically used for software modules that a vendor provides along a core product
• there are good arguments that abbreviations and any jargon is a barrier, thus excluding people (which society then responds to with inclusion measurements); besides it is understood as one defining aspect of fascist language (see the works of Viktor Klemperer and T.A. Adorno), i don't mention this as incrimination whatsoever, but pointing out that it can turn people off
• given that it is a distinct set of documents from the "main" documentation it seems prone to confusion when also available from the same domain with a path prefix; it also wouldn't be consistent, e.g. there's no https://docs.python.org/packaging
• i would still reiterate that most used web clients offer enough "assistive technology" ([synchronized] browsing histories, bookmarks, auto-completion) to deal with the general information overdose, so that the typing effort can be neglected in an assessment for naming things

Marietta wrote:

Maybe we can make all those proposed urls work and point to the one chosen url.

i'd answer that in the spirit of Tim's well-formulated guide that information retrieval is also well guided when it's rather "explicit" and there should be "preferably only one […] way" to retrieve a resource. also my experience is that maintaining redirects (on the webserver level where paths are also considered, not CNAME records in the DNS) is an often underestimated effort in the longer timeframe.