Re: [tz] Change Request: Europe/Kiev to Europe/Kyiv
A bit of necroposting from my August 2020 email (quoted in full below):
We should take the time to write up a good lengthy explanation of the issues ("boilerplate"), because this a really important issue of concern to many people in the world and the project has indeed thought about it pretty carefully. Dismissing the inquiries because they are repetitive makes it seem like we haven't, and that unnecessarily upsets [people].
Has anyone done any work on this, or given thought to it? Serhii Trykoza (hopefully cc'd)'s github PR from the last hour (https://github.com/eggert/tz/pull/35, copied far below) raises the issue again. 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. 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. Also, when you create a pull request on github now, it reports, "Be sure to review the contributing guidelines." with a hyperlink to https://github.com/eggert/tz/blob/228a93f759cd5f2b0cca9e05eeee3d7cdea07ebf/C.... It is not until the last paragraph of that file that any mention is made of pull requests ("[p]lease do not create [them]"), and 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. Convertinf the file to markdown and making the "please don't use github pull requests" the first thing, rather than the last thing, would help to get the point across. (Indeed, perhaps that should be the *only* thing in the file that github links to.) -- jhawk@alum.mit.edu John Hawkinson John Hawkinson <jhawk@alum.mit.edu> wrote on Sat, 15 Aug 2020 at 18:52:58 EDT in <20200815225258.GA62055@alum.mit.edu>:
Date: Sat, 15 Aug 2020 18:52:58 -0400 From: John Hawkinson <jhawk@alum.mit.edu> To: Paul Eggert <eggert@cs.ucla.edu>, Victor Perov <vic.gald@gmail.com> Cc: Time zone mailing list <tz@iana.org> Subject: Re: [tz] Change Request: Europe/Kiev to Europe/Kyiv Message-ID: <20200815225258.GA62055@alum.mit.edu> In-Reply-To: <eggert/tz/pull/27/c673663957@github.com> <cefc7f01-a3e9-f2a4-9ab9-5288147f994a@cs.ucla.edu>
I do not think we have handled this well; we have not given Victor Perov a good answer. Indeed, to some extent we've made it a "runaround." We can do better.
We should take the time to write up a good lengthy explanation of the issues ("boilerplate"), because this a really important issue of concern to many people in the world and the project has indeed thought about it pretty carefully. Dismissing the inquiries because they are repetitive makes it seem like we haven't, and that unnecessarily upsets peopl.
Victor Perev: I don't have time for a full write-up right now, but please consult the archives of the tz list (http://mm.icann.org/pipermail/tz/ or perhaps https://www.google.com/search?q=site%3Amm.icann.org%2Fpipermail%2Ftz%2F+kyiv which returns 203 results). The tz project is very conservative in its judgment for when the predominant English spelling of a city has changed, and so far the project has judged that Kiev is still preferred. We discussed it when major English newspapers and style guides changed from Kiev to Kyiv last year (prompted by the US presidential impeachment, which lead to a lot of discussion about Kyiv in America), and we will probably continue to discuss it as time goes on. But we've thought about it and discussed it a lot. The answers you got don't explain that, and that means we have not done a good a job as we should have. Sorry about that.
In particular, I think Brian Inglis's answer was actually incorrect in a way that really matters ("Kiev is the correct English spelling"). There are multiple correct English spellings. It used to be that Kiev was the only one, but Kyiv is gaining popularity more and more.
Paul Eggert <eggert@cs.ucla.edu> wrote on Sat, 15 Aug 2020 at 18:19:08 EDT in <cefc7f01-a3e9-f2a4-9ab9-5288147f994a@cs.ucla.edu>:
Thanks for bringing that to the mailing list (if I could shut off GitHub pull requests I would).
Although you cannot do so, we can handle them a little bit better. Please see https://docs.github.com/en/github/building-a-strong-community/creating-a-pul...
You can create a template that explains to a would-be pull request submitter than pull requests will be closed and the project uses the mailing list for development discussions. ("I understand that the tz project does not use pull requests on github, and that if I enter a pull request here, it will be closed and I will be directed to send email to tz@iana.org.")
For the particular case of regular, recurring issues, it may be worth while to keep one of #15, #26, and #27 open and mark the others as a duplicate of it, so that it is easier for newcomers to understand that this issue has been carefully considered and is not a simple oversight.
https://github.com/eggert/tz/pulls?q=kiev
Also, not to pick on Brian (again), but if the project policy is not to use github pull requests, it's not great to respond to pull requests on their substance, because it bifurcates the discussion and makes it seem like we actually do use pull requests ("except when we don't"). So what seems like a helpful thing may not be.
-- jhawk@alum.mit.edu John Hawkinson
Serhii Trykoza <notifications@github.com> wrote on Mon, 6 Dec 2021 at 08:17:35 EST in <eggert/tz/pull/35@github.com>:
Date: Mon, 06 Dec 2021 05:17:35 -0800 From: Serhii Trykoza <notifications@github.com> To: eggert/tz <tz@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: [eggert/tz] KyivNotKiev (PR #35) Reply-To: eggert/tz <reply+AAJWHPTK2DO6A5B34PZOC3N7XHXG7EVBNHHD7Z4WBI@reply.github.com> Message-ID: <eggert/tz/pull/35@github.com> X-GitHub-Sender: strikoza
In September 2020, the English Wikipedia switched from using Kiev to Kyiv.
https://en.wikipedia.org/wiki/KyivNotKiev You can view, comment on, or merge this pull request online at:
https://github.com/eggert/tz/pull/35
-- Commit Summary --
* KyivNotKiev - In September 2020, the English Wikipedia switched from using Kiev to Kyiv - https://en.wikipedia.org/wiki/KyivNotKiev
-- File Changes --
M .gitignore (2) M europe (4) M theory.html (2) M zone.tab (2) M zone1970.tab (2)
-- Patch Links --
https://github.com/eggert/tz/pull/35.patch https://github.com/eggert/tz/pull/35.diff
-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/eggert/tz/pull/35
On 12/6/21 05:43, John Hawkinson wrote:
Has anyone done any work on this, or given thought to it?
What I do is send email like the following to the commenter. 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. ---- 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. End users should see their preferred spelling which would typically be Київ, but could also be Kyiv, Kænugarður, Κίεβο, 基輔, or whatever else is appropriate for the user's locale. The Unicode Common Locale Data Repository (CLDR) is a good source for these localized names; see <http://cldr.unicode.org/>. If your software application is exposing the string "Europe/Kiev" to users who prefer a different name, please send bug reports mentioning CLDR to the application's developers. Thanks.
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.
Quite right. I've closed the PR. Further discussion should be on the tz@iana.org mailing list.
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.
I tried to do that a while ago, but it didn't appear to take. I just looked again at this issue now; see its commentary on Dear GitHub <https://github.com/dear-github/dear-github/issues/84>. Disabling pull requests has been requested for five years, but GitHub hasn't implemented it yet. And all the workarounds have problems. 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.
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.
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? 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....
On 12/6/21 13:09, Paul Eggert via tz wrote:
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.
While doing that I found one pending pull request from Stephen (attached) which I installed. The idea is that future changes can just be emailed to this list.
On 12/6/21 13:19, Paul Eggert wrote:
While doing that I found one pending pull request from Stephen (attached) which I installed.
Oops, I didn't notice that Trinidad and Tobago already had that comment in the 'southamerica' file, which is arguably a better spot for the comment as the country is entirely on South America's continental shelf. Further patch attached. Sorry about all the chatter.
Paul Eggert via tz said:
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.
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?
On second thought, switching from text to Markdown might not be worth the trouble.
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 can read plain text; let's leave it there. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
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." How do we feel about inline images on this mailing list? Here's a screenshot of what I see: [image: Screen Shot 2021-12-06 at 16.31.29 a.png] When you follow the "contributing guidelines" link, it takes you to https://github.com/eggert/tz/blob/f6c9f51fac212b5d5c6a74b6e41dbd2c20f294f6/C..., 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 can read plain text; let's leave it there.
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. -- jhawk@alum.mit.edu -- jhawk@alum.mit.edu John Hawkinson +1 617 797 0250 On Mon, Dec 6, 2021 at 4:10 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
On 12/6/21 05:43, John Hawkinson wrote:
Has anyone done any work on this, or given thought to it?
What I do is send email like the following to the commenter. 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.
----
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. End users should see their preferred spelling which would typically be Київ, but could also be Kyiv, Kænugarður, Κίεβο, 基輔, or whatever else is appropriate for the user's locale. The Unicode Common Locale Data Repository (CLDR) is a good source for these localized names; see <http://cldr.unicode.org/>. If your software application is exposing the string "Europe/Kiev" to users who prefer a different name, please send bug reports mentioning CLDR to the application's developers. Thanks.
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.
Quite right. I've closed the PR. Further discussion should be on the tz@iana.org mailing list.
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.
I tried to do that a while ago, but it didn't appear to take.
I just looked again at this issue now; see its commentary on Dear GitHub <https://github.com/dear-github/dear-github/issues/84>. Disabling pull requests has been requested for five years, but GitHub hasn't implemented it yet. And all the workarounds have problems.
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.
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.
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?
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....
On 12/6/21 13:43, John Hawkinson wrote:
there are plenty of contexts in which tzids are indeed visible to users, whether they are "looking under the hood" or not.
That language was intended to express the tzdb's project intent, which admittedly is not necessarily the same as how the project data are used. I'll try to remember to say this more explicitly next time.
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).
It'd be odd to have CONTRIBUTING.md with some GitHub-specific text saying essentially "You're on GitHub and so are barking up the wrong tree", along with some other file *not* named CONTRIBUTING that gives advice about contributing. Since the Markdown-enabled friendliness for GitHub doesn't matter much now that pulldown requests are "temporarily" prohibited, I'm becoming more inclined to go back to plain-text CONTRIBUTING.
On 12/6/21 05:43, John Hawkinson wrote:
It is not until the last paragraph of that file that any mention is made of pull requests ("[p]lease do not create [them]")
After more thought I went back to this first suggestion, and put "please do not create pull requests" at the start of the CONTRIBUTING file, going back to plain-text format. Although this is not as spiffy-looking on GitHub, it should be good enough to address what remains of the original problem. There is some advantage to sticking with plain text over Markdown as tzdb already has two other markup formats - HTML5, and man pages - and proliferation of markup formats has its own problems. Had GitHub supported CONTRIBUTING.html it might have been a different matter. I did leave a few Markdownisms in CONTRIBUTING (when they look fine in text too), and backported some of the minor improvements to CONTRIBUTING that I had made to the Markdown version. I'm attaching both a 'git diff -b' between last week's CONTRIBUTING and the new, and the newly-installed proposed patches.
Do you really not want PRs? I think the issue is where discussion happens, not how code lands... Eliot On 14.12.21 18:26, Paul Eggert via tz wrote:
On 12/6/21 05:43, John Hawkinson wrote:
It is not until the last paragraph of that file that any mention is made of pull requests ("[p]lease do not create [them]")
After more thought I went back to this first suggestion, and put "please do not create pull requests" at the start of the CONTRIBUTING file, going back to plain-text format. Although this is not as spiffy-looking on GitHub, it should be good enough to address what remains of the original problem.
There is some advantage to sticking with plain text over Markdown as tzdb already has two other markup formats - HTML5, and man pages - and proliferation of markup formats has its own problems. Had GitHub supported CONTRIBUTING.html it might have been a different matter.
I did leave a few Markdownisms in CONTRIBUTING (when they look fine in text too), and backported some of the minor improvements to CONTRIBUTING that I had made to the Markdown version.
I'm attaching both a 'git diff -b' between last week's CONTRIBUTING and the new, and the newly-installed proposed patches.
On 12/14/21 23:53, Eliot Lear wrote:
Do you really not want PRs? I think the issue is where discussion happens, not how code lands...
If the development repository accepted pull requests, there would be two places where discussion would occur: one on tz@iana.org and the other in the GitHub PR threads. It's better to have just one place. I expect this sort of thing is why Linus Torvalds disabled PRs for the Linux kernel: he already had an established procedure for PRs via email, and didn't want to deal with two discussion areas. Although GitHub PRs have some advantages, it's not clear that they outweigh the advantages of the mailing list for tzdb.
participants (4)
-
Clive D.W. Feather -
Eliot Lear -
John Hawkinson -
Paul Eggert