The Roadmap for SFML 2.6 and SFML 3 has been relatively unchanged for quite a while, yet I see very little movement from the community, then again as mentioned in the linked thread, people seems to be really eager for a more modern C++ code base, as such people may just be waiting until SFML 3 finally kicks off.
We had cleaned up the
SFML 2.6 project on GitHub quite a bit in the past and just today, I basically removed anything that would require additional work or discussion and updated the Roadmap.
As for the longer discussion...
I'm highly biased so my comments may not reflect reality 
There are multiple levels to all of this and it's hard for me to bring it to the point, but I give it a try.
In the SFML 1.x and early 2.x periods we had Laurent as the driving force behind SFML, pushing a lot of topics forward on his own and seeing them through from idea to final implementation.
Over the past years we tried to turn the project into a more community-driven mode, but the big success is still unaccounted for. Here are a few observations of mine:
SFML has a high quality standardWe try to get the code (and commits) as good as possible before merging them. This leads to Pull Requests not being accepted (but also not rejected) that don't meet that "quality". The advantage is that once a feature is merged, it has been tested, is stable and usually doesn't require regression fixes.
Personally, I don't think we should make compromises here, as it would only reduce the quality and push the required work further back.
SFML is cross platformA lot of people underestimate the amount of work required to implement a "simple" feature. You have to pick an API design for SFML, then you need to make sure that it works for Windows, Linux and macOS and then you need to implement for all these platforms and after all that, there's still Android and iOS.
I could see some room for providing feature implementation for just one platform, but this has the danger of diverging the feature sets and making the library less "cross-platform".
Technical DiscussionsIt's tedious and requires time, but it's essential to have technical discussions. Very often people feel offended or walk away when they get confronted with questions.
It's not enough that you like a feature or that you already coded said feature. In order to keep the API simple and maintainable, we need to consider the broader use-cases for a feature. Once you know the 'why', the question moves to the 'how', which usually offer multiple designs that need to be weighed one against the other.
I'm the first to admit that we had a lot of discussions that ran a bit out of hand in the past, but let's try and leave the past in the past. I think it's essential to have discussions on topics, at the same time, if someone provides a complete implementation of a feature and provides some good arguments why this is a valid use-case, it's rare that it will be outright declined.
Active Discussionsbinary1248 has created various pull requests with potential changes and made them public so everyone can take a look, provide feedback and scrutinize the design decisions taken. But the activity on these PRs are very low. If we want to move forward, we do need active conversations - those are often the more valuable contributions!
Nobody owes anything to SFML, but you also need to understand how it personally frustrates me, when there's a
draft pull request with only two comments on it and on the other side, people pretend that SFML is dead and lacks some features. If you want a feature, you need to get active and help get the feature finished.
ChampionsIn an ideal world the SFML Team would pick up existing pieces and completely new features and start pushing them forward until they reach the finish line. But being more community-driven this responsibility would now be with everyone. Unfortunately, we still get a lot of contributions that are well intended, but get stuck after the first or second review or discussion point. I understand that the excitement goes away after the first few hours or days, but it's crucial that features are not just thrown over the fence and left for others to finalize, but that the author (or some other contributor) champions the topic. That means: rebase whenever there are merge conflicts, implement review comments, ping reviewers, keep the discussion on open questions active, etc.
SFML is relying on the community, as such the will to do something is not enough. I also want to spend more of my free time on SFML, but often end up doing other things. Pick a topic, start a discussion and champion it from start to finish, that's how SFML is moved forward.
tl;dr- Join and/or start discussions on topics that you're interested in
- Champion already existing topics and push those over the finish line
- Right now: SFML only progresses if the community works on it, so let's get to work!
