Hi All, In advance of next Thursday’s meeting, I’ve been doing some work on tickets, mainly moving fixed, closed tickets into the 3.0.0 milestone (https://github.com/TEIC/TEI/milestones/Guidelines-3.0.0 https://github.com/TEIC/TEI/milestones/Guidelines-3.0.0). This looks like a really good way to easily point to what’s been done for a given release! I’ve created a 3.1.0 milestone we can use to capture work that happens towards the following release. I think in the future that as soon as we mark a ticket "Go", we should also give it a milestone. We have 38 tickets in a Green state (https://github.com/TEIC/TEI/issues?q=is%3Aopen+is%3Aissue+label%3A%22Status%... https://github.com/TEIC/TEI/issues?q=is:open+is:issue+label:%22Status:+Go%22), meaning there should be no obstacles to their implementation. Can I ask you all to have a look through these and ask a) is this really Green? Does it need more discussion or is it blocked? b) if it’s assigned to you, can you do it, or do you need to hand it off? c) If you’re not assigned a ticket, but think you could do it and are sufficiently bored, can you take it over? It would be nice if we could get at least some of these into 3.0.0. Some of them have been around an awful long time. On Thursday, we need to decide if we’re ready to "freeze" for the release, when that release will be, and who will be the release technician. This will be only our second release from GitHub, and the first under our new repo organization scheme, so we’re essentially doing this for the first time. Git Flow, which we’re emulating, recommends something like the following as a release procedure: 1) Create a release branch - Changes made during the run-up to release should be made here, then merged back into dev - Given this separation, there should be no need for an actual freeze on dev, but no big changes should be merged into release. 2) Merge the release branch into master 3) Push master to GitHub. Ideally, this would trigger a test process, à la https://github.com/TEIC/TEI/issues/1411 https://github.com/TEIC/TEI/issues/1411, which is not in place yet 4) Assuming tests pass, tag the release 5) Post release, the release branch can be merged into dev and removed. From there on, more or less as in http://www.tei-c.org/Activities/Council/Working/tcw22.xml http://www.tei-c.org/Activities/Council/Working/tcw22.xml, which needs some work (which itself is a problem due to the brokenness of the TEI website CMS). Thoughts?