Flicking through responses so far, I tend to concur with many that more tools is not what I need, nor do I feel any springing to mind as needed. But given I do love FOSS and I contribute to it a little in my spare time as and when I need something that isn't there my main desire in terms of products/tools would be anything at all, that makes the process of creating and submitting PRs (Pull Requests, a fancy git era term for a submitted code contribution or patch) simpler, more discoverable and intuitive and streamlined is a big thing I'd like to see.
This part of a broader wish to see community collaboration improve even more. It has seen unprecedented advances in the last decade, but I think is still one of the areas in need of attention to lower the barriers in a sense.
For example, if all IDEs started to converge on a standard open project definition format and build and publish formats ... that would already be a boon. The biggest issue I see in the world around me, I have seen repeatedly described by like-minded individuals as Forking F-in forking!
That essentially every part of the development cycle is dominated by a disorienting and challenging number of options confronted every step of the way, and if you look at n projects you find a call to learn a handful of different tools every step of the way etc.
And so perhaps the biggest product I would like to see existing is "more standardisation". It requires flexible standards, but more than that, it requires competing tool sets to start thinking about conformance to one another bit by bit. A pipe dream, I know. But I dream. And I have seen standards emerge. Browsers are a case in point ... the divergence between them has shrunk to inconsequence. It is doable. We need to share the vision broadly, though ;-).
The mantra being: lower entry barriers, leverage familiarity.
For Git and GitHub specifically, tools like git-town and GitHub's gh (the successor to hub) have short commands for creating PR's. I'm not sure anything addresses making PR's more discoverable. Not sure what you mean by more intuitive, though I agree there's a moderate learning curve to using PR's.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Flicking through responses so far, I tend to concur with many that more tools is not what I need, nor do I feel any springing to mind as needed. But given I do love FOSS and I contribute to it a little in my spare time as and when I need something that isn't there my main desire in terms of products/tools would be anything at all, that makes the process of creating and submitting PRs (Pull Requests, a fancy git era term for a submitted code contribution or patch) simpler, more discoverable and intuitive and streamlined is a big thing I'd like to see.
This part of a broader wish to see community collaboration improve even more. It has seen unprecedented advances in the last decade, but I think is still one of the areas in need of attention to lower the barriers in a sense.
For example, if all IDEs started to converge on a standard open project definition format and build and publish formats ... that would already be a boon. The biggest issue I see in the world around me, I have seen repeatedly described by like-minded individuals as Forking F-in forking!
That essentially every part of the development cycle is dominated by a disorienting and challenging number of options confronted every step of the way, and if you look at n projects you find a call to learn a handful of different tools every step of the way etc.
And so perhaps the biggest product I would like to see existing is "more standardisation". It requires flexible standards, but more than that, it requires competing tool sets to start thinking about conformance to one another bit by bit. A pipe dream, I know. But I dream. And I have seen standards emerge. Browsers are a case in point ... the divergence between them has shrunk to inconsequence. It is doable. We need to share the vision broadly, though ;-).
The mantra being: lower entry barriers, leverage familiarity.
For Git and GitHub specifically, tools like git-town and GitHub's gh (the successor to hub) have short commands for creating PR's. I'm not sure anything addresses making PR's more discoverable. Not sure what you mean by more intuitive, though I agree there's a moderate learning curve to using PR's.