holman
commented
8 years ago Hey Dan,
So that About page one was kind of a strange thing, looking back. Someone initially started it and I eventually finished it with another designer. At the time we didn't really have a good idea of what the final page would look like, so the pull itself had a ton of iteration involved in it as we kept trying things out.
This was from a much different era of GitHub- both pull requests themselves weren't quite as capable, and internally we didn't have a feature flag mechanism set up (or at least streamlined). So much of the development happened locally rather than out in production.
Compare that to the current About page, which I think I revamped in like 2013 or 2014 or something. I'm pretty sure that was done behind a feature flag and had a bunch of pulls involved in it. That's more along the lines of how I'd advocate doing things nowadays. Keep the pull requests really small and really short.
As an example, for something epic like GitHub's Issues 2.0, did you keep the pull request open while constantly merging staff-shipped code up into master?
When we did Issues Three (2.0 came out a few years prior), it probably was a couple hundred pull requests over three-quarters of a year or so. We were probably the most productive three-person team at GitHub, and we were able to push these really tiny pull requests out constantly throughout production and get a real feel of how the new code worked and behaved.
All these pulls would be on different branches, though, with the vast majority of them being named after funny inside jokes or pop culture references. If we wanted to tie them together we'd use issue references to create a pathway from pull to pull. With large subprojects, we'd open up a meta tracking issue and use Task Lists to make sure everything got done in an orderly fashion. I really like that approach rather than using an entirely new tool to manage project process, in large part because you can easily show other people in your GitHub organization and get their feedback on things.
Hope that helps! Let me know if you have any more questions on any of this, though!
As you've mentioned in earlier posts, most pull requests should be small and frequent to reduce large changes, and ship often. However, occasionally GitHub has highlighted its "epic" pull requests, that might have 130 commits and 91 comments from 10 different people over a two month timespan. These approaches seem to be at odds with each other.
In order to support an epic pull request, you've previously mentioned that feature flags are often used to staff-ship early code into
masterlong before a feature is ready for public consumption. However, what I'm not entirely clear about is whether or not you would continue to keep the original branch and pull request open when that code has been merged tomaster. I assume such staff-shipped changes would be getting pushed tomasterall the time but it's unclear if you'd want to keep the pull request open all the while to keep the conversation in one place.As an example, for something epic like GitHub's Issues 2.0, did you keep the pull request open while constantly merging staff-shipped code up into
master? And if so, how exactly would you do that if GitHub automatically closes the Pull Request once a branch's code is merged intomaster? (Does the command-line bypass automatic closing of pull requests?)Thanks in advance!