many open pull requests

[hexxt-git]

I have been refraining from opening even more PRs since there are so many open already but new features are being merged in. the older ones should get priority to be merged, closed or get a comment.

@crynta what is the road map here

[crynta]

@hexxt-git You're actually right and I started changing CONTRIBUTING/ROADMAP.md yesterday because doing this solo is just too much and I can't keep up with all the PRs.

My plan was to check older PRs first to clear them out, but urgent stuff keeps popping up, like security, terminal/shell issues (after BetterStack's video for example), performance optimizations, etc. I have to fix those myself as fast as possible, so the PR queue just piles up in the meantime.

Tbh, it was my mistake for not making a roadmap from day one. A lot of PRs don't really fit the direction of the project, and even closing them takes time because I hate just saying a dry "no" to people who put effort into it.

I'm working on the roadmap and new guidelines right now to fix this. Thanks for calling it out

[jwvanderbeck]

Don't be afraid to have an opinionated project. Many projects these days auto-close PRs until a discussion or issue has existed and discussed. This serves two very important functions. First it allows you the opportunity to discuss the feature/change with a person to determine if it fits with your vision or not before they actually do the work and submit it, and two it allows you to filter out clankers who are just trying to make changes through their AI to make the software do what they want.

The last one is a bigger problem them many people realize. In this new world of AI it is very easy to essentially personalize open source software to the way you expect it to work, then everyone thinks they should contribute that back without considering that the original developers may have a different vision.

The Issue/Discussion first allows alignment. If someone wants to take it in a different direction than you desire, that discussion happens first and the developer can fork.

[griffinbird]

Have a look at the contributos.md and the PR/Issue process for pi.dev. I think this a good approach. Tough, but safe guards and creates control.