Someone starts a new #FOSS project as a hobby activity.

[smallcircles@social.coop]

Many good insights brought up.

Have my mastodon closed now to not be distracted all the time

Btw, though many were boostworthy I didn't boost any toot, as it would only increase my (moral/ethical induced) workload to reply.

In that sense discussing on fedi is no fun. Most people aren't up to par with branches in the thread, and you become kind of content manager / entertainer that points out all the duplicates or repeats themself.

[ireneista@adhd.irenes.space]

@smallcircles yeah... Discourse really is better for most forms of substantive discussion, in that way

[smallcircles@social.coop]

@hyc @akdb

If they feel unreasonably and unjustifiably entitled, then sure yes (and it helps to still be polite in telling them, if only to save yourself from more drama). But did you convey what you consider to be improper entitlement? What expectations have you raised in your communication and behavior without being aware of it? Is there an expectation mismatch, and could you have prevented the negative cycle to deal with mutual misunderstandings? Could you have mitigated risk for your sake?

[smallcircles@social.coop]

@ireneista

I run 3 forums and self-host 2 of those, one via Docker, one via Yunohost. Quite a few dev communities are on @Discourse

Dunno if there's a shift to alternatives now, but #Discourse used to be the best choice feature-wise, stability/quality-wise for hosting that kind of open community. Some modern forum software has appealing minimal UX, good enough for visitors / members, severely lacking for moderators / admins and to organize more intricate community governance.

[unexpectedteapot@social.linux.pizza]

@smallcircles at this point I should print a tshirt out of it: microblogging is not designed for discussion.

[smallcircles@social.coop]

@unexpectedteapot

It might read:

> Mastodon! THIS IS NOT UP FOR DISCUSSION.

[akdb@mastodon.social]

@hyc "Fuck off" is a bit rude...

@smallcircles
I feel that it isn't the developer's responsibility to set and communicate expectations about the direction of the project with anyone outside their team. I don't know why, it just feels like it. (But of course it you want to set expectations, to reduce the comments or otherwise, by all means it's your project.)

I didn't know about the burnout! I'll make sure to voice my gratitude for people and their work a lot louder.

[hyc@mastodon.social]

@akdb @smallcircles demanding that people who gave you free labor do even more for you is beyond rude. It's the height of selfishness. These people are invariably, as a rule, a timesuck. The wisest course of action is to drive them away as fast as possible.

The only people who deserve a say in how things are done are people who contribute to getting things done.

[akdb@mastodon.social]

@smallcircles Not to invalidate the burnout and pressure and negativity that anyone is feeling, but, isn't it possible to simply not listen to commenters? Especially once someone realises that fufilling many feature requests and patching bugs quickly is ruining their fun. I can't see why the demands would be a problem if the developer just continued at their own pace (as BDFL :)). Please tell me what you think.

[smallcircles@social.coop]

@hyc @akdb

I do think that investing time to ensure expectations match is well worth it for the developer too.

You can quickly prep this at the start of a project, and with few efforts monitor and adjust if mismatches start to appear again.

After all, when not doing that, once you start getting the criticism it will cost you a lot of wasted time and negative energy trying to deal with it.

[smallcircles@social.coop]

@akdb

It is possible to create your project without issue tracker and/or ability to submit pull requests to change the codebase. SQLite is an example of that. Because direct participation is impossible, people follow the procedures outlined by the dev team to try to influence project direction. That is done a much more manageable way now, whereby the expectations have been set appropriately.

I don't do this ignoring input will backfire and lead to a spiral of more nastiness coming your way.

[smallcircles@social.coop]

@akdb

It is possible to create your project without issue tracker and/or ability to submit pull requests to change the codebase. SQLite is an example of that. Because direct participation is impossible, people follow the procedures outlined by the dev team to try to influence project direction. That is done a much more manageable way now, whereby the expectations have been set appropriately.

Not doing so and ignoring input will backfire and lead to vicious spiral of nastiness coming your way.