RFC 66: Use GitHub for RFCs #66
Conversation
|
By nick.colley on 2017-02-17 15:13:00.116 The closed nature of our wiki makes it really hard to collaborate with the communities across GDS so I'm very in favour of this. This would also allow people outside of GDS to see the kinds of problems we're dealing with and learn from them. We should make sure to make the distinction between GOV.UK and GOV.UK Publishing so therefore I'd be up for helping the migration efforts |
|
By paul.bowsher on 2017-02-17 17:12:26.039 I'm definitely in favour of this, but we'll need a programme level decision on whether the repo should be public or not. It'd also be nice to try and migrate the comments - sometimes they can be as valuable as the RFC. |
|
By paul.hayes on 2017-02-24 14:06:15.052 Have we discussed anything in existing RFCs that we know couldn't have been written publicly? Our Trello boards, repositories, etc are all open by default. |
|
By paul.bowsher on 2017-02-24 16:24:46.466 I've skimmed up to RFC 50 from RFC 18 and it all looks fine. Can someone else please read past that and make sure we've not said anything we wouldn't want to be made public? |
|
By paul.bowsher on 2017-02-28 10:43:17.977 I've checked all of these now and they're all fine apart from the one about GovDelivery. I've redacted the monthly cost and softened the language slightly. |
|
By david.silva on 2017-02-20 14:09:07.887 Thumbs up from me on this. paul.bowsher wouldn't a private repo defeat the purpose of the first point made?
|
|
By paul.bowsher on 2017-02-20 14:13:39.367 Github has more granular permissions than Confluence. We could open it up to other people in GDS but not to the public. |
|
By thomas.natt on 2017-02-20 14:28:41.179 I'm in favour, although I second Paul saying we'd need a higher decision before making this completely public. I also question whether a fully public discussion forum would discourage certain groups of people from commenting. I know I'd be less happy discussing (and especially asking some basic questions) in full view of the public. Slightly different question - what is the feeling about the third problem ("It's hard to keep track of changes to RFCs during the proposal period"). This suggests the wiki watch and history facilities aren't adequate which has knock-on considerations for other areas. |
|
By natalie.baron on 2017-02-20 15:38:28.900 Hello - just a question about who you want/who would want to respond to RFCs. If you only need feedback from people who use Git then it's all good. Or if it's easy to notify people there's something for them to see even if they don't have an account, that sounds good too. |
|
By paul.bowsher on 2017-02-22 10:21:54.766 Good question. This is traditionally tech-only but there's been some valuable feedback from non-tech in the past. This won't preclude non-tech people from commenting as anyone can create a Github account and comment through the web interface. Likewise interested people can subscribe to notifications for the repository, but this might reduce engagement if it's not baked into Confluence. Moving these to Github would open them up to people outside of GOV.UK but slightly increase the friction for non-tech people when commenting. I think this is probably a reasonable trade off, but would like to know how often non tech people read and monitor these. |
|
By natalie.baron on 2017-02-22 10:40:20.747 As a non-tech person with a Git account now, I wouldn't know where to start with subscribing to notifications (albeit I could probably work it out), but more to the point, I'm not sure I'd know which repositories I might want to keep track of (if any - would subscribing to a repo mean getting every change on it?). Not sure what other non-tech people do though. |
|
By paul.bowsher on 2017-02-22 10:51:32.970 That's fine, we'd make sure that was well documented. You'd only need to subscribe to one repository, the one containing the RFCs. |
|
By natalie.baron on 2017-02-22 11:51:14.323 That sounds great. |
|
By david.silva on 2017-02-22 12:35:45.677 Likewise interested people can subscribe to notifications for the repository, but this might reduce engagement if it's not baked into Confluence. I normally use this application to keep track of Pull Requests https://ptsochantaris.github.io/trailer/ That's useful because I don't have to open another browse page constantly to see if there's any comments or new pull requests. I'm sure there's other ways of keeping track, maybe we should document them. |
|
By tim.blair on 2017-02-28 12:00:22.432 Yes. We need to do this. Massive 👍 for the principle of moving RFCs to GitHub. However, I do think we need to put a little bit more thought. For example:
I'm assuming by this that you mean to use PR numbers to number the RFCs? This only works if the only thing that an issue or PR is raised for is to propose a new RFC. If someone submits a PR to fix (e.g.) a typo or broken link in an old RFC, or having pre-RFC discussions via an issue, then it messes up the numbering. We need a bit more in terms of "implementation details" before ploughing ahead with this. Maybe something based on / similar to the very successful RFC process used by Rust? From a migration perspective:
|
|
By tijmen.brommet on 2017-03-23 11:59:23.868 I've changed the status of this RFC to "Accepted" because I think there's broad consensus that moving this to public GitHub is a Good Thing. It's still an open question how to actually migrate to GitHub. If I recall correctly, tim.blair was looking into this. |
|
By tim.blair on 2017-03-23 12:42:19.377 Yes, currently thinking over questions like:
I've spoken to paul.bowsher about some of this, but once we've something a little firmer, I'll circulate for wider feedback. |
|
By paul.bowsher on 2017-04-03 15:14:08.936 I've got an example repo available at https://github.com/alphagov/govuk-rfcs for people's perusal. It's generated using this script. I've got a throwaway bot account on Github that I will use to populate the repo. The only things that aren't in there at the moment are images and other attachments. I think as the bot is linking back to the original RFC this is probably ok. Most of the images are reaction gifs in comments. Any critical images can be added to the git repo and linked as needed. Next step: proper approval from people that this approach is good, then I'll re-run the script from scratch with the latest comments and open up the repo. |
|
By nick.colley on 2017-04-03 15:25:37.476 We should consider naming this |
|
By paul.bowsher on 2017-04-04 07:00:45.732 The name of our programme is officially "GOV.UK", and we don't include "Publishing" in any other names of repos. |
|
By nick.colley on 2017-04-04 11:04:15.258 I think there's good reasons why we should change that, it makes it really hard to collaborate with the rest of GDS since people have trouble understand what is GOV.UK the brand and what is 'Publishing'. This is feedback I've had from outside Publishing (who can't see this comment thread of course) |
|
By tim.blair on 2017-04-04 11:06:34.997 There have been discussions about this, and I'm sure there will continue to be so. But it's totally out of scope for this RFC. And if we ever do change our name, this repo will be one of the easiest things to change. |
|
By nick.colley on 2017-04-04 11:10:29.508 For me, we're doing this to make our RFCs open for the same people who will find this name since it's so generic. Seems like a good opportunity to make change in this area. |
|
By paul.bowsher on 2017-04-04 11:15:49.868 I've already asked this question of Neil, and he says we're called GOV.UK. There are conversations in the programme team about this but as Tim says that's a much bigger scope than this RFC. |
|
By tijmen.brommet on 2017-04-03 17:41:10.375 Really cool! Would you be able to sort the RFCs in such a way so that they retain their version number as PR number? That will make linking easier. |
|
By paul.bowsher on 2017-04-03 17:48:04.265 Yeah probably but I doubt they'd stay in sync for long. I fully expect each RFC to be amended by future PRs. |
|
By tim.blair on 2017-04-04 11:08:00.158 I think initial PR number for version number is reasonable. And I'm not convinced that accepted RFCs should be updated after the face: they should be superseded by a new RFC. |
|
By paul.bowsher on 2017-04-04 15:12:51.358 I think it'd be nice to try and keep it that way, but I think it'd be unsustainable. Changes to READMEs etc would require a new PR, and then the numbers would be out again. I also think that "hey I spotted a typo" wouldn't require a whole new RFC to supersede an old one, or some small clarification like "yes, sorry, everything except MapIt". Those should be easily fixed with a new small PR on an existing RFC. |
|
By tijmen.brommet on 2017-04-04 15:51:51.339 Rust has it both ways. Accepted RFCs get the same number as the originating PR, and allows for fixup PRs. For example: rust-lang/rfcs#1960 is "Fix typo in RFC 1574", which lives at rust-lang/rfcs#1574. I don't think it's a problem that there are gaps in the resulting numbers (https://github.com/rust-lang/rfcs/tree/master/text) |
|
By tim.blair on 2017-04-04 16:04:01.952 That's fair. There's also nothing to stop issues being raised on the repo (in fact, we may want to encourage folks to do that to have pre-rfc discussions). It's worth considering that RFC numbers to not have to be monotonically incremental. Somewhere up there ↑ I suggested considering at least taking some inspiration from Rust's RFC approach, which assigns RFC numbers only once accepted, and then based on the PR number: https://github.com/rust-lang/rfcs |
|
By tim.blair on 2017-04-04 16:04:39.647 Yes, just what tijmen.brommet said down there ↓ |
|
By paul.bowsher on 2017-04-04 16:47:14.268 Yep. I'll try and work out a nice way to maintain the numbering then. This could be fun... |
|
By paul.bowsher on 2017-04-05 09:45:59.186 Ok, I think that's got it all: https://github.com/alphagov/govuk-rfcs/pulls |
|
By jenny.duckett on 2017-04-03 17:50:20.614 Naming the files so they sort correctly in the directory would be good too. |
|
By tim.blair on 2017-05-05 13:22:06.987 Implementation consideration: Open Standards are using GH milestones for tracking "open until" dates: https://github.com/alphagov/tech-and-data-standards/milestone/1 |
|
Merged with note: Accepted, but implementation might vary |
No description provided.