Add a Humans.txt File

Funny that I now have a vague memory of Everett closing that over 12 years ago now. I did search for references, but apparently, missed this.

Not a lot of folks have installed the Humans.txt module, but why would folks? It's just a text file and a metatag reference. Not worth the burden of a whole module.

That said, Google things there are over 16 million references to humans.txt in URLs.

This is the first I've heard of this concept but I love it.

Like any documentation, there is a chance for it to become out of date if it is not tied to the source of truth. It makes sense that the packager could auto generate the humans.txt file directly the way it generates portions of the info file.
That way it would essentially include information the the same way composer pulls it into the .lock file

 "authors": [
                {
                    "name": "Jeroen Tubex",
                    "homepage": "https://www.drupal.org/u/jeroent",
                    "role": "Maintainer"
                },
                {
                    "name": "benjy",
                    "homepage": "https://www.drupal.org/user/1852732"
                }
            ],

Though I guess there is a difference between maintainer.txt and human.txt. So maybe pulling in maintainer data is out of scope.

I 100% support this! It is a great and non-intrusive addition to core's codebase.

I think @swirt is right. Any given list of authors will be outdated at some point in the future.

I suggest we add shortest file we could as proposed by @mgifford in the issue description, so to say just a humans.txt file pointing to the list of maintainers - because this list is updated frequently:

/* Team */
    See core/MAINTAINERS.txt

If it were meant to be edited by site owners we would scaffold it and people would have to append to it or patch it. But isn’t the point of this file to credit the people who built that given site?

there was a module for that in D7.
https://www.drupal.org/project/humanstxt →

As the creator of the Omega 4 Logo, who pledged to add it as a default favicon tho the theme, I would NOT add something to core, which has to be filled before go live. As I saw everywhere big websites with the default omega 4 Logo, I know, that nobody will change something which is a default, before go live :) I think we should have a d10 Module and for people who like to support it, should install/configure the module or add it in their distribution etc..

Don't get me wrong. I really like and support a humans.txt, but just would not put it with default content into core.

Nico

That was the conclusion in #1278846: Adding humans.txt to Drupal core → .

• This would be an easy, unobtrusive addition to core
• There's already a module that could be used, why complicate this issue?
• I propose it's just a text file with an agreed upon format
• If you want to keep it up to date, or build it automatically, let's create another issue for it?
• I'm sorry if I am missing something, it feels like this is an easy change.

@swirt, I like your YAML style direction, but it is different than what is proposed here:

https://humanstxt.org/Standard.html

Maybe something like this:

/* Drupal Core Maintainers */
    See core/MAINTAINERS.txt

/* Site - see https://humanstxt.org - for format suggestions */

/* Please add site specific contributions below */

/* TEAM */

Your title: Your name.
Site: email, link to a contact form, etc.
Social Media: whatever you use   
Location: City, Country.

							
/* THANKS */
					
Name: name or url

                            
/* SITE */

Last update: YYYY/MM/DD           
Standards: HTML5, CSS3,..
Components: Modernizr, jQuery, etc.

I am sorry, but it seems like people are each looking at this with a slightly different take and I think it is because the purpose is not clear.

The current purpose says

Well, it would be useful to point folks to both the Drupal issue queue as well as the Maintainers.txt file in a humans.txt file.

Could we maybe change this to a user story or two in order to clarify the goal(s)?

Proposing a humans.txt file in core in this MR.

Seems to have a test failure.

But having a hard time understanding the usefulness. Another file to point to the MAINTAINERS.txt file? If more detail was added maybe some usefulness.

All tests pass now.

Regarding the usefulness, I think it is just to promote the Humans.txt initiative.

We already have an example file for bots (e.g. robots.txt).

It is fair to have an example for humans too.

I tested this on a clean install. The starter file of humans.txt appears in the docroot as it should.

I don't think it's fair to most of our contributors to only refer to MAINTAINERS.txt. Thousands of other people have contributed to Drupal and if we are going to do this, it feels like we should credit them equally.

As a point of reference, Symfony has a CONTRIBUTORS.md which contains the name of everyone who has contributed to their project: https://github.com/symfony/symfony/blob/7.1/CONTRIBUTORS.md

I think there is a misunderstanding. The new humans.txt file generated by drupal scaffold - see attached MR !6249 - does not aim to promote Drupal contributors. The idea is to provide a file by default to promote its usage. It aims to be customized for each Drupal project with the people involved.

I think it is not related to Drupal itself.

Sites can do this if they want already. I assume that 99% of sites that they won't do anything with this and the scaffold tool will simply put the default file in place. If we do add this, how are site owners supposed to discover that it needs to be updated, and how are end users supposed to discover humans.txt?

https://humanstxt.org/humans.txt has not been updated since 2012 according to the timestamp in the file, so is this even still relevant? Other large sites seem to use this to advertise jobs:

https://www.google.com/humans.txt
https://www.netflix.com/humans.txt

https://news.ycombinator.com/item?id=33740259 has some further discussion which is worth reading. Personally I don't think there is any value in implementing this in core - unless we are to go all the way and add every Drupal contributor ever - but that doesn't stop individual sites from implementing it if they choose to do so.

IF this is implemented, should the file be added as well to the .gitignore file?

There is a contrib module → , which does this thing. Also it is possible to add this file separately, without the need of any module (and any core hacks). What are the expected benefits for Drupal, if we add it to the core?

The contrib module has a very low usage and not sure, that this file is used by many sites to be something, that would be necessary to have at the core.

I am also a bit confused, if the file is intended to be read by humans (as there is practically no structure in the humans.txt "standard"), would not it be better to generate a page on d.o. with a list of all contributors to the core instead? Such a page would also have a formatting and will be indexed by search engines.

It aims to be customized for each Drupal project with the people involved.

Then I think the scaffold process should not create a file named named humans.txt, but instead example.humans.txt, as the file is not intended to be used without further modifications.

@mgifford, thanks for revisting this idea. I have read this issue, the comments and the originating issue.

I agree with #3 → and #4 of the original issue. There is a distinction between the people building Drupal core and the people who are 'behind a website' or 'contributed to building the website'. Drupal core is just one the tools used to build a website. A website reflects the philosophy of the organization that owns the site and not necessarily the philosophy of Drupal.org, Drupal Association or any of the many core contributors.

I don't think there is any value in implementing this in core

I agree with longwave here.

The humans.txt file contains information about the different people who have contributed to building the website.

This statement from the MR confuses the builder of the tool with the builder of a website. And I do not want anyone to confuse the fact that I helped build the tool not the website they are viewing.

I support closing this as won't fix as was the original issue.

removing tag per the guidelines.

I agree with #24, we should close this as won't fix.

quietone → closed merge request !6249