Discourse, inspired by the change to CWs Show more
I feel like if you are pissed because average users are not joining a whole new technical platform and learning how to use it and then scrolling through pages and pages of incomprehensible tech jargon *just* to learn about new features in advance and object to them where necessary, you are probably doing things wrong.
My original post is more about pre-release though, with potential features being reviewable by average users *before* the feature makes it into a release. To prevent you putting in all the work and then feeling bad when people don't like them. So you don't have to roll it back or get a lot of grief for keeping it. You know?
@cassolotl @maloki @HeckTheCistem Whenever I work on something I post about it in the patron discord, and sometimes it leads to discussions where I find out if something is wanted or not. Now yeah, the discord is paywalled by $1 (though devs and instance owners can request an invite link from me anytime). But I'm not gonna apologize for that paywall. I release my work for free for the benefit of all, but I'm not gonna let people yell at me for free.
@gargron @cassolotl @maloki @HeckTheCistem perhaps adopting a form of final comment period similar to what Rust does might be a good idea. you still post stuff in the patron discord, but then you'd wait a week for people to comment on it before merging, or developing depending on how you feel
I doubt that Rust's RFC system would work here considering how the dev team is mostly just you, but an FCP might help
@HeckTheCistem @maloki @cassolotl @gargron Rust solves this by having a newsletter that sends out once a week, and FCPs take two weeks. the newsletter also notes recent PRs and interesting recent discussions
I wouldn't mind helping curate such a thing as a way of getting more people involved sooner, while still discouraging people from just at-ing you
@cassolotl @clar @HeckTheCistem @maloki Look, I'm not making bank on this. I think I'm slightly above German minimum wage. In the open-source scene, that's a great accomplishment. Compared to Twitter's 200 engineers, that's nothing. But it's my passion and I have fun doing it, so we get the Mastodon that we see. Don't mess with that. If you disagree with my decisions, fork, or switch to one of the existing forks. I listen to feedback. But I don't *owe* anyone to agree with it.
@cassolotl @maloki @HeckTheCistem @clar People want different things. The more people, the more different things they want. I have to juggle it all, find compromises where possible, choose who to disappoint where not. I mean, some get disappointed even by compromises. This is not a happy place. Hell, that whole CW thing was started from some people's requests. Or the search stuff the other week. Not a happy place.
@Gargron I understand. I mean, I've been there with you.
@Gargron @maloki @HeckTheCistem @clar Right! What Clar's suggesting is a solution that would give everyone a chance to be opinionated *before* you merge major features, so that you have as much information as possible as early in the game as possible, so that don't have to roll things back so much and be so frustrated. It wouldn't prevent all problems like this, but it would prevent a bunch of them.
@clar @HeckTheCistem @maloki @Gargron (I relate to the part where it's not always possible to compromise and even sometimes the compromise is *unacceptable* to some people. I do this survey of nonbinary people, these days >10,000 respondents. I often get people telling me I'm being transphobic. It sucks, I always feel like I'm doing it Objectively Wrong no matter what I choose, when it's actually totally subjective all round and at the end of the day it's my passion project that I do for free.)
All feature requests would be spearheaded by a volunteer, who would facilitate feedback. It would be unreasonable for you to be the one to refute every change you make, hence having a team who would take up this responsibility to gather feedback and only reject a change if a good alternative is given
@clar @Gargron @cassolotl @maloki @HeckTheCistem One of the hardest parts of developing #floss is that non-devs' sense of ownership over the work is often greater than their own contributions, pulling devs in different directions without matching support.
It makes a huge difference if people are helping & tipping.
Also we have to ask: why can't Mastodon be the place where conversations about it happen?
@clar @byron @Gargron @maloki @HeckTheCistem I'm not sure why people keep bringing the whole money thing into it to be honest. It's like, yes, Gargron is being paid close to minimum wage to lead development of a social network that like 150,000 people use regularly, yes, that is not really reflective of the hard work and the resulting goodness, but we're talking about a way to make feature requests discussion more accessible to regular non-technical stakeholder users, right?
@cassolotl @clar @byron @maloki @HeckTheCistem Let's be clear, feature requests are "I want this" and "I want that". The act of requesting a feature is not a noble selfless sacrifice, it serves the requester just as much if not more than it serves me.
In the FOSS environment, you are capable of scratching these itches yourself, I'm not the only one who can do it. If you don't know how to code, you can hire a developer to implement it for you.
@Gargron @clar @byron @maloki @HeckTheCistem I don't know how this is in any way unclear. I'm operating from the assumption it's a good thing to have feedback from a diverse and representative group of users about proposed features before you merge them, to avoid situations like this where people are upset/inconvenienced and you have to roll back your hard work. I agree with everything you just said, and I'm talking about something else. But it's clearly not working, so I will stop here. :D
That said, the fact that there hasn't been a merged PR in the past 30 days from anyone other than him (excluding translations), while there remain over 30 PRs from that time frame from other people which are unmerged, seems to contradict the idea that people want to help.
@gargron @HeckTheCistem @maloki @byron @cassolotl Like I've basically given up on the idea of providing PRs considering how most of the ones from outside developers get ignored. And I even have an open PR where I've mentioned you repeatedly that has since been ignored completely.
Like, I've mostly gotten the impression that people *have* to just do feature requests because actual features don't get merged.
@clar @Gargron @HeckTheCistem @maloki @byron Indeed, and this conversation is just making me feel bad because I can't code. Like, I always thought that feedback and ideas from average users was good and important, and what's been said here today kinda says the opposite - if I can't code it myself or pay someone to do it, I have no meaningful contribution to give.
@clar @HeckTheCistem @maloki @byron @cassolotl Again though you're sorta focused on this one repository, and pushing the features *you* want to *everyone* via me. You can fork, you can run your fork on your own servers, you can completely ignore me.
Yes, I'm very picky about what goes into my repository. Sometimes things don't fit into my release schedule because I can't take risks with someone else's code. But PRs by other developers do get merged regularly.
@kaniini Ohhhh that is unfair.
@kaniini I believe you, but that doesn't mean it's okay to be harsh just because other people have been more harsh to other other people!
I don't mind people venting on their own TLs about this stuff, but just venting at us is super annoying when we're trying to have an actual conversation. If you're not contributing, please don't reply to the thread.
1. Create a team of developers who understand your desires for the project, know the plans for release, and can offer their help implementing features.
2. Create a team of volunteers who can improve community outreach and collect feedback.
3. Have more community-run resources to help accumulate people for the above two.
Definitely the way Mastodon is growing, it will need a team. The trick is, though, managing a team of coders is *more* work on top of coding itself, and it's a different set of skills, too. So it's up to Eugen to decide how to approach it, and on what timeline -- and he has a very good point re. forking. In fact it's very much in the spirit of Masto for different instances to try forking for features, UI changes, etc.
@Gargron @clar @HeckTheCistem @maloki @byron I am curious, because there are a LOT of PRs, some very old, that have not been merged and you're saying you can't take risks, which is understandable and fair enough. But you kinda leave those people hanging, they're all like, "so is anyone going to merge this, or...?" So I guess I'm wondering why you don't just close them. Is it in case they are good and you do decide to merge them one day?
@cassolotl @maloki @gargron @HeckTheCistem IMO the main goal here is to create something that is not overwhelming for any one person, but also helps address the needs and desires of the community. and IMO those two things don't conflict at all
I'm offering the idea of a group of volunteers, being paid nothing, who can help improve community engagement. not asking an already overwhelmed person to get more work to do
@clar @cassolotl @maloki @Gargron @HeckTheCistem As I see it. @Gargron is doing a good job. He doesn't have to listen, but do anyway. Being restrictive with a safer path is exactly what he should do. His work affect more than a million people.
Which is why it becomes difficult to just trust someone. Trust takes time.. with or without funding.
Every feature implemented means extra work. Even if he didn't create it at first, he will have to maintain it. So picky is exactly what he should be.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!