3 ms·
> It can be a grind working on a project where everyone is mostly independent but coordinated. Most OSS projects have no project management or support staff to
by aleph_minus_one 3y ago
> It can be a grind working on a project where everyone is mostly independent but coordinated. Most OSS projects have no project management or support staff to help. In fact, most projects frown on companies providing that service to a project because it looks like control.
> "It is often hard for those working so hard to say no. Many find it hard to self-monitor for burnout and few know how to step away without full decoupling."
This should give a hint towards a solution: add some support stuff to shield off the developers (of course these people are not authorized to issue directives to the developers - we are not at a commercial company).
- delfinom 3y agoOffering commercial support doesn't really help unless developers also take a hard stance at that point and immediately close all filed issues that aren't bugs. I do see that happen alot in OSS, too many people use issues as help forums and too many people enable it.
- aleph_minus_one 3y ago> Offering commercial support doesn't really help unless developers also take a hard stance at that point and immediately close all filed issues that aren't bugs. I am not sure whether such a hard stance is necessary. Why not rather strongly deprioritize filed issues that are not bugs (i.e. it will be left open, but only worked on if ressources are available, which might be months to years)?
- bordercases 3y agoClogs the priority queue with trivial comparisons that are still necessary to make. If its really valuable it will come up again until a person that really does need it pays for it in labour money and so on. The issue can be archived and made a live option again anyway. Quality of life improvements fall by the wayside in this model, but that is a separate degree of motivation.