I think it's great that we're using Git and Github as the experimental / unofficial repository at https://github.com/eggert/tz. It's much easier to track change history looking through the commit log and see the changes than by reading through emails with patch attachments. However, we're not currently taking advantage of all that this environment has to offer. -- Item 1 -- We should be making better use of branches. We currently have a single "master" branch that everything gets committed to. This is problematic, because it doesn't separate things that are certain to be released from things that are proposed changes. For example, the recent time.tab file, and the other large-scale proposed changes that are currently being debated, could have been created on feature branches. This would have given the tz list members a place to look at the proposed changes and make additional suggestions (via pull requests) before things are finalized. As it sits today, since everything is in master, if the proposal is ultimately defeated then new commits will have to be made to master to revert these changes. The danger comes if, say we needed to issue an emergency release sometime in between. Since master isn't in a state of positive agreement, then one would have to branch from an earlier point in history to build a hotfix release, then merge that hotfix back to master later. It's much easier if we can just trust that master always consists of things that are certain to be released. See also: https://www.atlassian.com/git/workflows#!workflow-feature-branch http://www.git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging -- Item 2 -- I think that we should all make better use of forking and pull-requests for submitting proposed changes. Instead of submitting a patch file to the mailing list, one should fork the GitHub repo, make their changes, then create a pull request. This allows for place for discussion on proposals where the code can be referenced much easier. It also ensures that the author of each and every change is tracked in the commit log. And finally, it makes it much clearer which proposals were adopted and which were not. Presently, looking through the mailing list archives, it's quite difficult to tell if any given patch was actually applied or not. -- Item 3 -- We should decide how the GitHub issue tracker fits in to the ecosystem. I see that there have been a few issues reported to via the issue tracker in the past, but most things have come through the mailing list. If we adopt the conventions used by other modern projects, then we should be reporting bugs through the issue tracker so their history can be more easily found. Another benefit is that you can reference issue numbers in commits, and you can reference commits in the comments of an issue. This linking makes it quite easy to find the code or data that was changed in response to an issue. The mailing list should probably be used for extended discussion, rather than as a place to report issues. Though, there may be some blend of both, I personally think that an issue tracker is much more palatable than a mailing list for many of these kinds of things. There should probably be some guidance document on the iana tz page about what goes where. -- Item 4 -- While Paul Eggert is the tz maintainer, and I appreciate his efforts greatly, I personally don't feel that it's appropriate for the github repo to be in his personal "eggert" account. There should instead be a common "organizational account" for the project, such as github.com/tzdb or similar. ("iana" is taken, but appears to be unused or abandonded. Someone may want to inquire about obtaining it, as "github.com/iana/tz" would be quite appropriate IMHO). Though Paul would be the administrator of this account, his own personal account would no longer be authoritative. That also ties back to the idea of pull-requests. Since Paul makes the majority of changes, he would first make them in his own account, and then send a pull-request to the main account. Then a link could be sent to the mailing list for discussion on the pull request before it was merged in. As a side note - I've found that several third-party projects are linking to the unofficial sources using git submodules. While this isn't officially sanctioned, it would be much better if they could link to iana/tz instead of eggert/tz. -- Item 5 -- While code and data often go hand-in-hand, there are quite a lot of projects these days that only rely on the tz data. There are also a lot of releases of code changes that don't require data changes. Having both code and data in a single project seems rather inefficient. I propose that they be split back to separate projects, and maintained in separate github repos (tzdata / tzcode). Also, consider also that perhaps there are too many merged projects just within the code. For example, tzselect, zic, zdump, etc. might be broken out for better visibility of changes and for clarity of dependent files. I look forward to feedback on these items. I'm sure not all will be in agreement, but I think it's important that we look forward to new and better ways to manage this project - rather than just sticking with the ways of the past. -Matt