Project organization

[buhtz]

How is xrdp project organized? There are 8 year old bugs and 6 year old PRs.

There should be a plan or a standardized process how old bugs are treated. I assume most of them can be closed because the problem is not relevant in the current version or the bug reporter does not give feedback anymore.

From the marketing point of view it does not give a good picture about a project when the counter for Issues and PRs is so high. Only the fresh commits I can see indicating that the project is not dead.

[hardening]

@Codeberg-AsGithubAlternative-buhtz welcome to the real life with old bugs and PRs.

[matt335672]

Indeed!

I think we'd all like more time to spend on bugs and PRs; they're an extremely useful source of real-world problems and are used to drive meaningful changes.

However, we're all volunteers here, with a few hours a day at most to move the project forward.

Issues and PRs have a better chance of being acted on and moved forward if the author makes a real effort to engage with the project. I don't think we're significantly different from other free software projects in this regard.

[buhtz]

Please do not take this personal. This is not about real life, freetime and time managment. It is known and totally accepted that a project like this has low resources.

But even with low resources Issues/PRs could be managed a way. Do not merge them, do not fix them, but handle them.

Close a PR if you can not merge it. Or before someone even contribute a PR signal her/him that it won't be merged because of time and other priorities.

You have old Issues? Monitor them. No feedback after some weeks? Ask back if it is still relevant or if anyone want to add something to it. Monitor it. If again no feedback after some weeks. Close it. Thats it.

There are different approaches to handle situations like this. IMHO a GitHub-autoclose-Bot is the badest and most inpolite choice but it is up to you.

Simple approach: Alternate between the oldest and newest issue. Then you can new thinks/problems take into account but also work on the old things.

Having such old and much Issues and PRs open signal every new possible(!) contributor that this project is dead or out of control. Even the old this-is-done-in-free-time-speech does not help to establish a good connection to possible new contributors.

Another hint: For new users it is not clear that this is a freetime thing. Your website and your name "neutrinolabs" indicate (at the first sight) that there is a company with paid developers behind it. Of course you should not waste your website to a more ugly one but maybe you should present more of your team and the people behind the nicknames.

[matt335672]

Thanks for the thoughts.

[buhtz]

One tool on the way to a solution would be Issue templates to redirect the reporting people before they write something.

https://github.com/Codeberg-AsGithubAlternative-buhtz/spielwiese/issues/new/choose

Such templates are not only about pre-fill the Issue text window and set default-labels but also redirect them to other resources e.g. "Questions" section or FAQ or Wiki or anywhere else.

[matt335672]

@Codeberg-AsGithubAlternative-buhtz - may I ask what your interest in this particular area is? What's driving your query?

I ask because I'm a little confused as to where you're coming from. You've expressed an opinion here:-

From the marketing point of view it does not give a good picture about a project when the counter for Issues and PRs is so high.

and here:-

Having such old and much Issues and PRs open signal every new possible(!) contributor that this project is dead or out of control. Even the old this-is-done-in-free-time-speech does not help to establish a good connection to possible new contributors.

These appear to be personal opinions to me. I've never considered looking at old issues and PRs for a project before I contribute to it.

Have you got any facts to back these up? At the moment I can see you feel quite strongly, but I don't think you're really making a case for us to really consider spending effort on this.

Case in point; I've just spent an hour or so preparing #1975. That's time I haven't spent on refactoring the SCP code, which is an important long-term target. There's no easy way to "just handle" issues like this that I can see.

[buhtz]

Dear matt, thanks for asking back and keep the discussion rolling on.

may I ask what your interest in this particular area is? What's driving your query? I ask because I'm a little confused as to where you're coming from.

It is an often be me experienced problem with some FOSS projects. So it is not specific to xrdp. It just hit xrdp this time because I tried to dive into the project (orga) because of some technical problems I had on Debian.

I've never considered looking at old issues and PRs for a project before I contribute to it.

Very interesting point of view. Should be researched how possible new contributors look and value/judge (?) new projects.

Myself I look into a project to find out if it is still on the run and if the maintaining people would take or waste my invested resources. Maintainers have to manage there own less resources. But contributes (or just me?) do it also. For example before writing a line of code that could result in a PR I open an Issue and ask if a feature/change like this would be accepted by the maintainers. I am not interesting to fork a whole project. My main goal to is always to contribute to the mainline-project. But not unusual often the problem for contributors start at the first step to find out which one of the dozens of forks is the current real maintained mainline.

That is why I look for indicators that give me an idea about the "health" of a project.