[tz] Change Request: Europe/Kiev to Europe/Kyiv

John Hawkinson jhawk at alum.mit.edu
Mon Dec 6 21:43:09 UTC 2021


Paul Eggert <eggert at cs.ucla.edu> wrote on Mon,  6 Dec 2021
at 16:09:57 EST in <55ed6fe5-bdbb-e3c6-a8ad-eb8fae79bdf2 at 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/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
> 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 at alum.mit.edu

--
jhawk at alum.mit.edu
John Hawkinson
+1 617 797 0250


On Mon, Dec 6, 2021 at 4:10 PM Paul Eggert <eggert at 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 at 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....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20211206/abb232ad/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2021-12-06 at 16.31.29 a.png
Type: image/png
Size: 450965 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/tz/attachments/20211206/abb232ad/ScreenShot2021-12-06at16.31.29a-0001.png>


More information about the tz mailing list