Paul Eggert <eggert@cs.ucla.edu> wrote on Mon,  6 Dec 2021
at 16:09:57 EST in <55ed6fe5-bdbb-e3c6-a8ad-eb8fae79bdf2@cs.ucla.edu>:

> What I do is send email like the following to the commenter.

I think we would generally all benefit from this kind of dialogue being publicly copied to the list.

> It's not clear that it'd be helpful to put this into a text file
> somewhere in the distribution, as people would probably not see that
> anyway.

To be clear, the purpose of drafting a boilerplate would be to have a comprehensive response to send to people who inquire that covers the basis in a neutral and fair way, and to resist the temptation to dash off a quick answer that may give the impression that we have not given due attention to the issue. It does sound like you've done much of that -- great! I wasn't advocating that it be a text file in the distribution, and I don't have an opinion on that.

For what it's worth:

----
|
| Thanks, we're aware of the renaming effort, and this has been a periodic
| source of discussion on the tz mailing list. I proposed a transition plan
| for Europe/Kiev → Europe/Kyiv here:
|
| https://mm.icann.org/pipermail/tz/2020-November/029542.html
|
| and I suggest you review that email thread. There's no rush; tzdb tends to
| move slowly about these things, due to compatibility concerns.
|
| By the way, the choice of spelling should not be important to end users, as
| the tzdb spelling is not intended to be visible to them.

I find this language to be disingenuous. Others may disagree, but we know that there are plenty of contexts in which tzids are indeed visible to users, whether they are "looking under the hood" or not. I know many on this list would like to believe otherwise.

> For now, I will do the workaround that looks like it has the least number of
> problems, and this is what Linus Torvalds has done with the Linux kernel.
> That is, I will use GitHub's "Temporary interaction limits" to prevent all
> pull requests (and a bunch of other things, none of which we need) for the
> next six months. The idea is to reimpose this limit every six months,
> indefinitely. This should make it unnecessary to move the "please don't
> issue pull requests" message to the start of the CONTRIBUTING file.

This appears to have worked, insofar as instead of there being a Create Pull Request button in the UI, I now see "An owner of this repository has limited the ability to open a pull request to users that are collaborators on this repository." Great.

> I tried changing CONTRIBUTING to CONTRIBUTING.md by installing the attached
> patches into <https://github.com/eggert/tz>, but I don't see how this has
> made the GitHub world that much friendlier. Could you explain? What GitHub
> URLs work better now than they did yesterday?

It is not first-class URL, but part of the pull request workflow, which is a bit stateful.
I began at https://github.com/eggert/tz/compare/main...johnhawkinson:token?expand=1, and I'm not 100% sure you'll see what I see. I suspecft you'll see "Choose two branches to see what’s changed or to start a new pull request."

When you follow the "contributing guidelines" link, it takes you to https://github.com/eggert/tz/blob/f6c9f51fac212b5d5c6a74b6e41dbd2c20f294f6/CONTRIBUTING.md, which is more pleasantly formatted for github contributors. That said, the text about pull requests remains the last thing, when it probably ought to be the first thing to tell github contributors (although not necessarily the first thing to tell contributors who are working from the source distribution -- such people have different expectations and requirements).

> On second thought, switching from text to Markdown might not be worth the
> trouble. Markdown has its problems (it's not portable enough, it's extremely
> limited, it confuses form with content) which means that changing
> CONTRIBUTING to CONTRIBUTING.md was perhaps a mistake. Of course we could
> always change it back....

I don't particularly think CONTRIBUTING.md should do everything that CONTRIBUTING did yesterday.
CONTRIBUTING.md should be a relatively github-specific document to tell people that we don't use Github for pull request or issue management, and explain how and why.
It could then refer to another more general document about contributing in general (probably it would be poor to have CONTRIBUTING and CONTRIBUTING.md with different content, though).

I don't really think the problems with markdown are a big concern here, though.

Clive wrote:

> Please let's stick to plain text. We may be using github to provide an
> accessible git repository, but I don't see why that means we have to use
> everything they provide even when it doesn't fit our work pattern. Everyone

--
jhawk@alum.mit.edu