It’s one thing for a startup to do this while small.
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.
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.
While it's only for enterprise customers, AWS has a weekly email containing upcoming launches which are under NDA. It also has what amounts to recaps of recent launches, blog posts etc. Only the launches section is not publically available.
The upcoming launches section is literally just an HTML table with two columns: service name on the left and a brief summary on the right like "Add support for X Y.Y". It's almost funny how so much effort goes into fancy blog design when the "real" news is just distributed through a basic plain text email :)
---
To a certain extent, roadmaps become redundant for enterprise customers too in that you start to influence feature request priorities via your dedicated account manager(s)
Vendors may often prioritise a feature requested by medium enterprise to keep them content since if they don't address their features in a timely manager, they may go elsewhere when their contract comes up for renew.
---
I suppose that's why UserVoice type of forums are always a wasteland because the big players can get all the attention?
It's also behind the scenes so perhaps naturally, the result you're left with is acres of "9999 votes for feature X, submitted 14 years ago" and a Product Owner saying "Sorry, no news to report on this just yet"
Apple is a poor choice, because they consider keeping their roadmap under wraps an not only a competitive advantage, but a core part of their company ethos.
Google provides rather detailed roadmaps for GCP, they are really useful. They are under NDA, but customers should be able to get access. I think this recent "C2C" announcement has link for signing up[1]. I was invited, and your account manager should be able to invite you.
My first reaction was very different from yours; the desire to dogfood feels excessive, to me, and negates the point in having a public roadmap in the first place.
Am I wrong for presuming that the people who would most care about GitHub's public roadmap probably aren't even GitHub users?
EDIT: Thanks for the replies, everyone. Seems like I hadn't fully comprehended the range of features available to paying members - given this knowledge, choosing to do the roadmap in this form makes more sense to me.
problem is, this roadmap doesn't contain any specifics in contrast whats required from startups. It's just a fancy way of saying "we gonna do more source code versioning stuff".
Can you explain why? I really don’t see the draw of public roadmaps. I buy a product because it works for me now. If there are improvements I need in the future the company either implements them or they don’t. A public roadmap doesn’t improve my experience at all. In fact, I might be less likely to buy the product.
This feels like it opens github up to the vocal minority to scream and yell publicly about features they want. Some of which could negatively impact other users. And github will have to succumb to the pressure of that minority.
> 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.
I can imagine "GitHub Discussions" [0] cutting off a significant number of Stack Overflow questions.
I'm fine with this, so long as the search engine optimisation is there. I often google for an issue with a particular framework or library, and rather than the first result being the documentation, the first result is somebody asking on SO about it. It would be great if the answer is "closer to the source", pardon the pun. It also means that related questions may be easier to find, and you may come across something else of interest while on the discussion page for that particular project.
It also means that rather than building up SO's capital, you're indirectly contributing to the open source knowledge base of a project. It'd be even better if the discussion were backed by a Git repo or something easily exportable so that you aren't tied to Github, though I suppose part of the motivation for this feature is doing exactly that.
Still, SO has been king for too long. And the king's crown has been looking rather tarnished for a little while now.
I really like the idea behind this feature. Being able to add a discussions 'forum' to my main project could be an excellent way to start building a community around the project.
Looking at the Discussions issue page - https://github.com/github/roadmap/issues/104 - it looks like this will be delivered to projects not in the Beta testing group sometime before Christmas?
Out of interest, are there any project admins around who can comment on how easy it is to moderate the Discussions threads? My one concern would be managing flame wars, and minimising inaccurate answers participants may offer each other.
I've seen a few startups (For example https://www.getoutline.com/) using the GitHub Discussions beta as a defacto support forum. I like that use case and it seems like it will help both developers and users.
For devs, you'll get a forum setup without requiring time/money to set up your own hosting, which is big for small or bootstrapped projects. It will also help move specific questions out of your issues section/ticketing system.
For users, it lowers the friction associated with getting support since many already have a GitHub account.
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.)
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 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.
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?
Such a mechanism would be an actual meaningful step for enabling access to poorer communities.
> It's 2020, the cost of an ipv4 address is more than $20 an address.
But arbitrary layers of NAT are free, so in practice this shouldn't actually block anyone. I haven't had a globally reachable IP address for any of my computers ever, and yet here I am on the web.
Are we so sensitive to racism that the word "master" is offensive? There is a task to change the default branch to "main".
Note: there is no "slave" branch.
Intent matters, not the literal meaning of the word taken a specific orthogonal context. Not a single person in the millions of developers ever had a perverse notion of what master branch means.
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.
For me, the core features that comprise my GH user story are:
- Code
- Pull Requests
- Issues & Labels
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.
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.
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.
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.
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.
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.
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).
This is our first time publishing such a roadmap, and it isn't 100% complete yet. More items will fill in over time. But we needed to start the journey somewhere!
Dark mode is coming. The foundational work we are doing first is to replace all our custom HTML and CSS with components that are more readily themable. This will also help us improve accessibility, and help us replace our mobile web site with a fully responsive UI.
Am I the only one who does not care about Dark Mode? I find it neat that someone cares about it enough to mention it is missing, over lots of other features that are missing.
I see it in lots of products and kind of ignored it, but is this a priority for users?
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."
This is a great idea - I use the equivalent all the time in Gitlab.
> We will add an option when submitting a pull request for review to auto-merge it if all checks pass and the pull request is mergeable into the target branch.
IMO they should also make it possible to enable after creating the PR, before the checks finish. That's how Gitlab works and it's really useful even beyond the single author repo they discuss - once you have your approvals and have addressed all the feedback you can enable merge on pipeline completion and move on.
I believe the direction is to keep GitHub focused on where developers want to be, and not become some bloated planning tool for project managers and enterprises
If you're looking for agile power-ups to GitHub Issues, there's a few great options in the ecosystem. Check out ZenHub if you're looking for things like issue dependencies, epics, multi-repo boards, etc. and want to stay in GitHub. GitKraken Boards are also a great option and integrate with their Git GUI.
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.
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?
From a certain perspective, this is what the :+1: and :-1: reaction emojis are for, although I haven't checked to see if those are accessible via the issue API
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.
[+] [-] danicgross|5 years ago|reply
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.
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.
[+] [-] pyromine|5 years ago|reply
Ex. https://docs.microsoft.com/en-us/power-platform-release-plan...
[+] [-] spondyl|5 years ago|reply
The upcoming launches section is literally just an HTML table with two columns: service name on the left and a brief summary on the right like "Add support for X Y.Y". It's almost funny how so much effort goes into fancy blog design when the "real" news is just distributed through a basic plain text email :)
---
To a certain extent, roadmaps become redundant for enterprise customers too in that you start to influence feature request priorities via your dedicated account manager(s)
Vendors may often prioritise a feature requested by medium enterprise to keep them content since if they don't address their features in a timely manager, they may go elsewhere when their contract comes up for renew.
---
I suppose that's why UserVoice type of forums are always a wasteland because the big players can get all the attention?
It's also behind the scenes so perhaps naturally, the result you're left with is acres of "9999 votes for feature X, submitted 14 years ago" and a Product Owner saying "Sorry, no news to report on this just yet"
[+] [-] saagarjha|5 years ago|reply
[+] [-] carlosf|5 years ago|reply
[+] [-] antoncohen|5 years ago|reply
[1] https://cloud.google.com/blog/topics/inside-google-cloud/ann...
[+] [-] AndrewUnmuted|5 years ago|reply
Am I wrong for presuming that the people who would most care about GitHub's public roadmap probably aren't even GitHub users?
EDIT: Thanks for the replies, everyone. Seems like I hadn't fully comprehended the range of features available to paying members - given this knowledge, choosing to do the roadmap in this form makes more sense to me.
[+] [-] JoyrexJ9|5 years ago|reply
[+] [-] shuringai|5 years ago|reply
[+] [-] techntoke|5 years ago|reply
[+] [-] ryanSrich|5 years ago|reply
This feels like it opens github up to the vocal minority to scream and yell publicly about features they want. Some of which could negatively impact other users. And github will have to succumb to the pressure of that minority.
[+] [-] frankjr|5 years ago|reply
I can imagine "GitHub Discussions" [0] cutting off a significant number of Stack Overflow questions.
[0] https://github.com/github/roadmap/issues/104
[+] [-] isiahl|5 years ago|reply
[1] https://github.com/vercel/next.js/discussions
[+] [-] Thorentis|5 years ago|reply
It also means that rather than building up SO's capital, you're indirectly contributing to the open source knowledge base of a project. It'd be even better if the discussion were backed by a Git repo or something easily exportable so that you aren't tied to Github, though I suppose part of the motivation for this feature is doing exactly that.
Still, SO has been king for too long. And the king's crown has been looking rather tarnished for a little while now.
[+] [-] rikroots|5 years ago|reply
Looking at the Discussions issue page - https://github.com/github/roadmap/issues/104 - it looks like this will be delivered to projects not in the Beta testing group sometime before Christmas?
Out of interest, are there any project admins around who can comment on how easy it is to moderate the Discussions threads? My one concern would be managing flame wars, and minimising inaccurate answers participants may offer each other.
[+] [-] chrisdalke|5 years ago|reply
For devs, you'll get a forum setup without requiring time/money to set up your own hosting, which is big for small or bootstrapped projects. It will also help move specific questions out of your issues section/ticketing system.
For users, it lowers the friction associated with getting support since many already have a GitHub account.
[+] [-] d0m|5 years ago|reply
[+] [-] oefrha|5 years ago|reply
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.
[+] [-] codeviking|5 years ago|reply
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.
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.
[+] [-] mrmonkeyman|5 years ago|reply
[deleted]
[+] [-] kd913|5 years ago|reply
Such a mechanism would be an actual meaningful step for enabling access to poorer communities.
[+] [-] slim|5 years ago|reply
[+] [-] ebg13|5 years ago|reply
But arbitrary layers of NAT are free, so in practice this shouldn't actually block anyone. I haven't had a globally reachable IP address for any of my computers ever, and yet here I am on the web.
[+] [-] ryanlol|5 years ago|reply
[+] [-] suyash|5 years ago|reply
[+] [-] fermienrico|5 years ago|reply
Note: there is no "slave" branch.
Intent matters, not the literal meaning of the word taken a specific orthogonal context. Not a single person in the millions of developers ever had a perverse notion of what master branch means.
[+] [-] bob1029|5 years ago|reply
For me, the core features that comprise my GH user story are:
- Code
- Pull Requests
- Issues & Labels
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.
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.
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.
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.
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).
[+] [-] gokhan|5 years ago|reply
[1] https://docs.microsoft.com/en-us/azure/devops/release-notes/...
[2] https://dev.azure.com/mseng/AzureDevOpsRoadmap/_workitems/re...
[+] [-] staysaasy|5 years ago|reply
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).
[+] [-] flixic|5 years ago|reply
[+] [-] natfriedman|5 years ago|reply
Dark mode is coming. The foundational work we are doing first is to replace all our custom HTML and CSS with components that are more readily themable. This will also help us improve accessibility, and help us replace our mobile web site with a fully responsive UI.
[+] [-] prepend|5 years ago|reply
I see it in lots of products and kind of ignored it, but is this a priority for users?
[+] [-] r3trohack3r|5 years ago|reply
Highly recommend. Also worth changing the default background color in Firefox to avoid burning your retinas every time a page loads.
[+] [-] jeffnappi|5 years ago|reply
GitHub - if you're listening, _PLEASE_ implement protected tags :)
https://github.community/t/feature-request-protected-tags/17...
[+] [-] catchmeifyoucan|5 years ago|reply
https://github.com/github/roadmap/issues/107
[+] [-] silviogutierrez|5 years ago|reply
You can self host if you want, easy on Heroku.
Plug and play.
[+] [-] mcintyre1994|5 years ago|reply
> We will add an option when submitting a pull request for review to auto-merge it if all checks pass and the pull request is mergeable into the target branch.
IMO they should also make it possible to enable after creating the PR, before the checks finish. That's how Gitlab works and it's really useful even beyond the single author repo they discuss - once you have your approvals and have addressed all the feedback you can enable merge on pipeline completion and move on.
[+] [-] cltsang|5 years ago|reply
I wonder if the plan to incorporate features from Azure DevOps is still on-going.
[+] [-] JoyrexJ9|5 years ago|reply
[+] [-] aupright|5 years ago|reply
[+] [-] gigatexal|5 years ago|reply
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?
[+] [-] rasz|5 years ago|reply
for example https://github.com/CnCNet/cnc-ddraw/files/4974882/ddraw.zip redirects to https://github-production-repository-file-5c1aeb.s3.amazonaw...
[+] [-] hankchinaski|5 years ago|reply
[+] [-] willow9886|5 years ago|reply
[+] [-] mdaniel|5 years ago|reply
[+] [-] open-paren|5 years ago|reply
[+] [-] factorialboy|5 years ago|reply
[+] [-] willow9886|5 years ago|reply
[+] [-] jborichevskiy|5 years ago|reply
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.
https://github.com/ipfs/roadmap
[+] [-] LockAndLol|5 years ago|reply