<div dir="ltr"><div dir="ltr">Paul Eggert <<a href="mailto:eggert@cs.ucla.edu">eggert@cs.ucla.edu</a>> wrote on Mon,  6 Dec 2021<br>at 16:09:57 EST in <<a href="mailto:55ed6fe5-bdbb-e3c6-a8ad-eb8fae79bdf2@cs.ucla.edu">55ed6fe5-bdbb-e3c6-a8ad-eb8fae79bdf2@cs.ucla.edu</a>>:<br><br>> What I do is send email like the following to the commenter.<br><br>I think we would generally all benefit from this kind of dialogue being publicly copied to the list.<br><br>> It's not clear that it'd be helpful to put this into a text file<br>> somewhere in the distribution, as people would probably not see that<br>> anyway.<br><br>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.<br><br>For what it's worth:<br><br>----<br>|<br>| Thanks, we're aware of the renaming effort, and this has been a periodic<br>| source of discussion on the tz mailing list. I proposed a transition plan<br>| for Europe/Kiev → Europe/Kyiv here:<br>|<br>| <a href="https://mm.icann.org/pipermail/tz/2020-November/029542.html">https://mm.icann.org/pipermail/tz/2020-November/029542.html</a><br>|<br>| and I suggest you review that email thread. There's no rush; tzdb tends to<br>| move slowly about these things, due to compatibility concerns.<br>|<br>| By the way, the choice of spelling should not be important to end users, as<br>| the tzdb spelling is not intended to be visible to them.<br><br>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.<br><br>> For now, I will do the workaround that looks like it has the least number of<br>> problems, and this is what Linus Torvalds has done with the Linux kernel.<br>> That is, I will use GitHub's "Temporary interaction limits" to prevent all<br>> pull requests (and a bunch of other things, none of which we need) for the<br>> next six months. The idea is to reimpose this limit every six months,<br>> indefinitely. This should make it unnecessary to move the "please don't<br>> issue pull requests" message to the start of the CONTRIBUTING file.<br><br>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.<br><br>> I tried changing CONTRIBUTING to CONTRIBUTING.md by installing the attached<br>> patches into <<a href="https://github.com/eggert/tz">https://github.com/eggert/tz</a>>, but I don't see how this has<br>> made the GitHub world that much friendlier. Could you explain? What GitHub<br>> URLs work better now than they did yesterday?<br><br>It is not first-class URL, but part of the pull request workflow, which is a bit stateful.<br>I began at <a href="https://github.com/eggert/tz/compare/main...johnhawkinson:token?expand=1">https://github.com/eggert/tz/compare/main...johnhawkinson:token?expand=1</a>, 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."<br><div>How do we feel about inline images on this mailing list? Here's a screenshot of what I see:</div><div><br></div><div><img src="cid:ii_kwv78z330" alt="Screen Shot 2021-12-06 at 16.31.29 a.png" width="578" height="341"><br></div><br>When you follow the "contributing guidelines" link, it takes you to <a href="https://github.com/eggert/tz/blob/f6c9f51fac212b5d5c6a74b6e41dbd2c20f294f6/CONTRIBUTING.md">https://github.com/eggert/tz/blob/f6c9f51fac212b5d5c6a74b6e41dbd2c20f294f6/CONTRIBUTING.md</a>, 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).<br><br>> On second thought, switching from text to Markdown might not be worth the<br>> trouble. Markdown has its problems (it's not portable enough, it's extremely<br>> limited, it confuses form with content) which means that changing<br>> CONTRIBUTING to CONTRIBUTING.md was perhaps a mistake. Of course we could<br>> always change it back....<br><br>I don't particularly think CONTRIBUTING.md should do everything that CONTRIBUTING did yesterday.<br>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.<br>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).<br><br>I don't really think the problems with markdown are a big concern here, though.<br><br>Clive wrote:<br><br>> Please let's stick to plain text. We may be using github to provide an<br>> accessible git repository, but I don't see why that means we have to use<br>> everything they provide even when it doesn't fit our work pattern. Everyone<br><div>> can read plain text; let's leave it there.</div><div><br></div><div>Again, I'd strongly recommend keeping any instructions to github users (As CONTRIBUTING{,.md} is/are) in markdown, because they display much more nicely to github users. DIrections for other contributors can (should?) go someplace else.<br></div><br>--<br><a href="mailto:jhawk@alum.mit.edu">jhawk@alum.mit.edu</a></div><br clear="all"><div><div dir="ltr" class="gmail_signature">--<br><a href="mailto:jhawk@alum.mit.edu" target="_blank">jhawk@alum.mit.edu</a><br>John Hawkinson<br>+1 617 797 0250</div></div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 6, 2021 at 4:10 PM Paul Eggert <<a href="mailto:eggert@cs.ucla.edu">eggert@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 12/6/21 05:43, John Hawkinson wrote:<br>
<br>
> Has anyone done any work on this, or given thought to it?<br>
<br>
What I do is send email like the following to the commenter. It's not <br>
clear that it'd be helpful to put this into a text file somewhere in the <br>
distribution, as people would probably not see that anyway.<br>
<br>
----<br>
<br>
Thanks, we're aware of the renaming effort, and this has been a periodic <br>
source of discussion on the tz mailing list. I proposed a transition <br>
plan for Europe/Kiev → Europe/Kyiv here:<br>
<br>
<a href="https://mm.icann.org/pipermail/tz/2020-November/029542.html" rel="noreferrer" target="_blank">https://mm.icann.org/pipermail/tz/2020-November/029542.html</a><br>
<br>
and I suggest you review that email thread. There's no rush; tzdb tends <br>
to move slowly about these things, due to compatibility concerns.<br>
<br>
By the way, the choice of spelling should not be important to end users, <br>
as the tzdb spelling is not intended to be visible to them. End users <br>
should see their preferred spelling which would typically be Київ, but <br>
could also be Kyiv, Kænugarður, Κίεβο, 基輔, or whatever else is <br>
appropriate for the user's locale. The Unicode Common Locale Data <br>
Repository (CLDR) is a good source for these localized names; see <br>
<<a href="http://cldr.unicode.org/" rel="noreferrer" target="_blank">http://cldr.unicode.org/</a>>. If your software application is exposing the <br>
string "Europe/Kiev" to users who prefer a different name, please send <br>
bug reports mentioning CLDR to the application's developers. Thanks.<br>
<br>
<br>
> Please note that the tz project does not use github PRs for issue tracking or commit management, so the PR will likely be closed in short order, which is not an indication of merit.<br>
<br>
Quite right. I've closed the PR. Further discussion should be on the <br>
<a href="mailto:tz@iana.org" target="_blank">tz@iana.org</a> mailing list.<br>
<br>
> Speaking of boilerplates, I want to again suggest that if this is going to continue to be the project policy, there should be a github pull-request template that makes it clear pull requests are not considered appropriate.<br>
<br>
I tried to do that a while ago, but it didn't appear to take.<br>
<br>
I just looked again at this issue now; see its commentary on Dear GitHub <br>
<<a href="https://github.com/dear-github/dear-github/issues/84" rel="noreferrer" target="_blank">https://github.com/dear-github/dear-github/issues/84</a>>. Disabling pull <br>
requests has been requested for five years, but GitHub hasn't <br>
implemented it yet. And all the workarounds have problems.<br>
<br>
For now, I will do the workaround that looks like it has the least <br>
number of problems, and this is what Linus Torvalds has done with the <br>
Linux kernel. That is, I will use GitHub's "Temporary interaction <br>
limits" to prevent all pull requests (and a bunch of other things, none <br>
of which we need) for the next six months. The idea is to reimpose this <br>
limit every six months, indefinitely. This should make it unnecessary to <br>
move the "please don't issue pull requests" message to the start of the <br>
CONTRIBUTING file.<br>
<br>
<br>
> the fact that the it's a plain text file (rather than CONTRIBUTING.md in markdown) makes it feel pretty unfriendly in the github world.<br>
<br>
I tried changing CONTRIBUTING to CONTRIBUTING.md by installing the <br>
attached patches into <<a href="https://github.com/eggert/tz" rel="noreferrer" target="_blank">https://github.com/eggert/tz</a>>, but I don't see <br>
how this has made the GitHub world that much friendlier. Could you <br>
explain? What GitHub URLs work better now than they did yesterday?<br>
<br>
On second thought, switching from text to Markdown might not be worth <br>
the trouble. Markdown has its problems (it's not portable enough, it's <br>
extremely limited, it confuses form with content) which means that <br>
changing CONTRIBUTING to CONTRIBUTING.md was perhaps a mistake. Of <br>
course we could always change it back....</blockquote></div></div>