It’s one thing for a startup to do this while small.<p>A whole other level of evolution to do it while you’re large. Imagine Apple suddenly publishing their roadmap. This type of organizational neurogenesis done as an adult is impressive.<p>EDIT: I am in admiration of the change, regardless of opinion on the value of public roadmaps. It’s just rare to see big companies make big changes. Sign of youthful vitality and health, in my opinion.
> Discussions live in your project repository, so they’re accessible where your community is already working together. Their threaded format makes it easy to start, respond to, and organize unstructured conversations. Questions can be marked as answered, so over time a community’s knowledge base grows naturally.<p>I can imagine "GitHub Discussions" [0] cutting off a significant number of Stack Overflow questions.<p>[0] <a href="https://github.com/github/roadmap/issues/104" rel="nofollow">https://github.com/github/roadmap/issues/104</a>
This is welcome, but anyone else feeling that GitHub is moving in the more-stuff-lower-quality direction? In particular I've wasted quite a bit of time over the past year on scarcely documented features and misfeatures around GitHub Actions. (To be clear I like GitHub Actions a lot.)<p>One example: just yesterday I found out that public images on GitHub Packages Docker registry can't be used in GitHub Actions' jobs.<job_id>.container, since the former is gated by auth for whatever goddamn reason and the latter can only pull from public registries. Think about it, their (probably #1) container-related feature can't use their own registry. Apparently people have been complaining for almost a year now, yet nothing has changed.
I love how well organized and executed this is.<p>I love that the issues each share a common format and provide concise yet clear documentation. The concise bit here is key -- I've had trouble perusing similar, open product roadmaps from other products because of the verbosity / level of detail.<p>Kudos to GitHub's team for doing such an excellent job in communicating and managing the roadmap. Particularly given the size or the organization -- this is no small feat.
It's 2020, the cost of an ipv4 address is more than $20 an address. Can there be some focus to include ipv6 support so that perhaps those people in the developing world who can't afford an ip address can access github and contribute?<p>Such a mechanism would be an actual meaningful step for enabling access to poorer communities.
Actual Roadmap with KanBan Board : <a href="https://github.com/github/roadmap/projects/1" rel="nofollow">https://github.com/github/roadmap/projects/1</a>
I really don't need a lot of fancy stuff in order for GitHub to be valuable to me or my organization. Honestly, I did not find much of the roadmap to be compelling.<p>For me, the core features that comprise my GH user story are:<p>- Code<p>- Pull Requests<p>- Issues & Labels<p>We also have limited use of Actions (for check builds) and heavy use of the API/Webhooks for integration with our own custom CI/CD tooling.<p>In my opinion, the biggest place where value should be added is in these 3 areas above. Some of the simplest ideas are the most powerful. We get an incredible amount of mileage out of basics like issues & labels. If there were additional aspects to issues similar to labels that could further enhance this experience, I would be very interested. Our entire development process revolves around issues to track tasks.<p>One of the things I've had in mind would be a way to build a markdown-defined webform template that can be used for populating highly-structured issues without requiring the user to edit a complex document each time.<p>For example, you could have CustomerTroubleTicketTemplate.md in a .github/issue_templates/ path, and then when you go to click New Issue, a down arrow could be provided that pops a list of all defined issue templates. Selecting one would present the user with a webform (as defined in the template markdown) that collects all required fields to create that issue. The issue could be created with labels/assignments/etc as defined in the markdown document. This would likely require enhancements to GFM.<p>Bonus points if there is some way to expose specific issue templates through public GH pages so that your customers can submit tickets against your private repositories even though they don't have direct access to your issue buckets. I think a very small step in this direction could obviate a lot of use cases people find with products like Zendesk (it would for us, anyways - we just funnel ZD tickets back into GH issues).
It's a longtime practice of Azure DevOps (former TFS) team [1][2] and many from that team are now working under GitHub. Maybe that's a culture transfer from MS.<p>[1] <a href="https://docs.microsoft.com/en-us/azure/devops/release-notes/features-timeline" rel="nofollow">https://docs.microsoft.com/en-us/azure/devops/release-notes/...</a><p>[2] <a href="https://dev.azure.com/mseng/AzureDevOpsRoadmap/_workitems/recentlyupdated" rel="nofollow">https://dev.azure.com/mseng/AzureDevOpsRoadmap/_workitems/re...</a>
Kudos to Github for trying this. I'm excited to see more SaaS companies "call their shots" and provide insight into their roadmap plans. It seems like a natural evolution of the industry.<p>For any enterprise SaaS businesses trying this at home – keep in mind that any product information that you publish publicly can and likely will be used against you by a competitor in a sales cycle at some point, fairly or unfairly. This might still be worth it overall, but is a real risk that isn't obvious until it happens to you (or you observe your team doing it to someone else).
How about basic feature parity with GitLab?<p>GitHub - if you're listening, _PLEASE_ implement protected tags :)<p><a href="https://github.community/t/feature-request-protected-tags/1742" rel="nofollow">https://github.community/t/feature-request-protected-tags/17...</a>
Super excited about auto-merge for PRs. "Today, the workflow for these users entails submitting pull requests and then coming back to the site to merge and delete the branch."<p><a href="https://github.com/github/roadmap/issues/107" rel="nofollow">https://github.com/github/roadmap/issues/107</a>
Interesting that there's no mention of agile tools like Project cards, issue dependencies, etc..<p>I wonder if the plan to incorporate features from Azure DevOps is still on-going.
whoever or whatever team came up with the personal README's for ones github profile needs to be given the keys to all of Github because no feature in all of my years of using github has had such a profound "cool" factor than this. It will also go a long way to solidify the site as a social network. I see it replacing my resume, I will just send people that link, much like I used to with a personal website.<p>The roadmap is nice and it's nice that we might get to see what is going on or coming up and maybe have a say in it. This seems a lot like what Gitlab is doing though, so perhaps they're trying to get some of Gitlab's goodwill?
I recently learned Github is internally using AWS, and not Azure, for file storage !?!?! :o<p>for example <a href="https://github.com/CnCNet/cnc-ddraw/files/4974882/ddraw.zip" rel="nofollow">https://github.com/CnCNet/cnc-ddraw/files/4974882/ddraw.zip</a> redirects to <a href="https://github-production-repository-file-5c1aeb.s3.amazonaws.com/110366814/4974882?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20200728%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20200728T195408Z&X-Amz-Expires=300&X-Amz-Signature=4cee8b39040095c810769cf56f2ac509b26d14cd09ae3d04b00d007b6d637492&X-Amz-SignedHeaders=host&actor_id=2623127&repo_id=110366814&response-content-disposition=attachment%3Bfilename%3Dddraw.zip&response-content-type=application%2Fx-zip-compressed" rel="nofollow">https://github-production-repository-file-5c1aeb.s3.amazonaw...</a>
More direct link to the roadmap: <a href="https://github.com/github/roadmap/projects/1" rel="nofollow">https://github.com/github/roadmap/projects/1</a>
In comparison, the GitLab Roadmap: <a href="https://about.gitlab.com/direction/" rel="nofollow">https://about.gitlab.com/direction/</a>
Kudos to them, I want to see more of this.<p>Another great roadmap I enjoyed reading through was the one of IPFS. Formatted somewhat differently (one long document) but still just gets me excited reading through it while communicating key objectives and milestones.<p><a href="https://github.com/ipfs/roadmap" rel="nofollow">https://github.com/ipfs/roadmap</a>
That's a really nice presentation.<p>I hope that they are able to pull it off. It's ambitious, but they now have a sweet sugar daddy, and can afford it.<p>I use GH for all my work, and look forward to seeing some of this come to be.
This is very good and interesting to see.<p>Also, now that it's public, it's interesting to see as a non-enterprise user, that many new planned features are going enterprise first<p>For example, private GitHub pages:
<a href="https://github.com/github/roadmap/issues/77" rel="nofollow">https://github.com/github/roadmap/issues/77</a><p>A long requested feature for private repos is going enterprise first. Not sure why, I don't know if this is purely business decision or if it has a technical reason
Great to see a roadmap so we have an idea what's coming.<p>A little OT, but what I'd love to see on the roadmap is rolling back the recent UI changes! Rounding every corner in sight just looks <i>wrong</i>; it doesn't "suit" GitHub. The accompanying layout changes also don't help.<p>I reacted the same way during preview, and after living with it for a few weeks I still feel the same - the recent UI changes still look and feel odd, like it was little more than busywork.
Interesting to see people opening issues for things they want when nothing in the README suggests that Github was seeking community input. I realize that this is possible due to the fact that it is an open source repository, but its possible the issues could get flooded and this repository becomes less useful?
Was actually hoping there would be more community features on the road map. I know I'm in the minority, but the promise of social coding is still out there waiting to be realized and more ability for open source projects to collaborate in diverse ways would be welcome.<p>But Github discussions seems interesting!
> Existing issues are currently read-only, and we are locking conversations, as we get started. Interaction limits are also in place to ensure issues originate from GitHub.<p>In other words: “our issue and community management functionality does not scale.”
It looks so bad... there are great tools out there that are built specifically for sharing your public roadmap with your users. Using GitHub for this is very rough on the eyes, and just bad for usability.
Sad to see that the biggest missing feature of github.com (and actually a simple one) is <i>not</i> on their roadmap, not even considered in the "future" section...<p><a href="https://github.com/isaacs/github/issues/1125" rel="nofollow">https://github.com/isaacs/github/issues/1125</a>
Glad to know they are working on this idiotic stuff: <a href="https://github.com/github/roadmap/issues/63" rel="nofollow">https://github.com/github/roadmap/issues/63</a>