Comment by md8z | Hacker News Reader

Comment by md8z | Hacker News Reader

Parent Full thread

I really don't agree with any of what you said. I have never been part of any internal clique and I've gotten patches in. The "examples" that I have seen posted around are bugs that get posted to hostile places like certain subreddits which then go and brigade the bug tracker which pisses everyone off. If you're having problems influencing people then you may have to get to know them first and learn what motivates them, it doesn't really make sense to skip this step and then sit on the sidelines complaining that nobody is listening to you or spending their time looking at your patch. If you cannot convincingly explain how your patch is going to help upstream then you have already failed, and that's the way it is with every open source project I've ever seen. It's a collaboration, it's not just dumping code over the wall.

I also don't know what you mean "volunteer excuse", it's not an excuse, that is the truth. Those people are unpaid volunteers doing it in their spare time, you deserve to know that so you don't get the wrong expectation. If they lack time or motivation to review a backlog of issues and merge requests then dumping more merge requests on them is probably not going to help. I'm sure you can think of other ways to help out there if you're really motivated.

> I also don't know what you mean "volunteer excuse", it's not an excuse, that is the truth. Those people are unpaid volunteers doing it in their spare time, you deserve to know that so you don't get the wrong expectation. If they lack time or motivation to review a backlog of issues and merge requests then dumping more merge requests on them is probably not going to help.

So open discussion is not accepted, changes to the plan are not accepted because they're volunteers and can't accomodate everybody, merge requests are not ideal because they don't have time to review them.

Pray tell me, how does one contribute to GNOME?

And I maintain that hiding behind "I'm just a volunteer, I don't have time for that shit" is an excuse, and a bad one. There's a lot of volunteers in the open source world, yet discussion and ideas flow more easily elsewhere.

> Pray tell me, how does one contribute to GNOME?

The same way you contribute to all other Free/Open Source project:

1) Make yourself useful and demonstrate that you are able. Start by fixing [Newcomers] bugs, participate in the Matrix chat and get to know people

2) Start influencing the direction of Gnome by participating in the design and contribute to larger, architectural issues

3) Get elected to the foundation leaderboard and become a decision maker

That's about it. Three easy steps. You can start here:

https://gitlab.gnome.org/GNOME/evolution/-/issues?label_name...

This plan is laughable. The number of people that could actually do this is limited. It’s like saying that participating in government will help change it. No, participation leads to complicity. It won’t change anything.

So your solution would be to not participate at all, ensuring that what you want has a 0% chance of ever getting done? Can't you see how that is strictly worse?

And yeah, of course the number of people who can do it is limited, not everyone is an expert in this stuff or has an interest in becoming one...

"Three easy steps". So, if I want to fix X or at least drive the discussion forward, I need to do menial jobs for 5 years, make a name for myself before I'm allowed to tackle X? How are we surprised nobody contributes to Linux desktop software?

> participate in the Matrix chat and get to know people

I'm a software engineer, your plan is teaching me how to get into politics. I understand that knowing people is important, but sounds to me that knowing people is the most important thing in the Linux desktop business. Not the type of environment I'd thrive on nor I'm interested in participating in. Sounds to me this version of "open-source collaboration" is just looking for politicians that put the effort to enter and fit into tight-knit, closed groups, not an open-air bazaar of people brainstorming and improving code.

It is no different from the "politics" you play at work every day. Your coworkers have to like and respect you (on some level) and you have to like and respect them or you will probably have a bad time. If you are new your boss probably won't give you the root password to the production database immediately, you have to work up to it and become senior within that company.

It's not clear what you want otherwise, if you want other projects that have a lower barrier for contribution, there are plenty of those, and they also have huge backlogs in their issue trackers. I mean just think of this from the other perspective. Say you are maintaining an open source project in your spare time. Somebody comes along and asks you to do something that would take up months of your time. And the fix is somewhat complicated so instead of spending your free time with your spouse/kids/friends/etc you would have to spend it all on that fixing that issue, for months, during which no other issues can be fixed. You could close the issue with an explanation, you could say you want it eventually and then leave it open, or you could totally ignore it and leave it open. But none of those options will ever be satisfying to the reporter, sometimes people just ask for things that are not realistic. I'm sure you can relate if you have paying customers at work that have ever asked for unrealistic timelines...

"So open discussion is not accepted, changes to the plan are not accepted because they're volunteers and can't accomodate everybody, merge requests are not ideal because they don't have time to review them."

Please avoid this hyperbole. If you actually look, there are plenty of examples of changes being accepted. But you have to play ball with them, like I said you can't just throw code over the wall and you can't just barge in and start trying to pick a fight with someone about the design.

"There's a lot of volunteers in the open source world, yet discussion and ideas flow more easily elsewhere."

If you have advice from those projects on how to improve process to make it easier to do it then please mention that. But otherwise I really don't know what you mean, I have had issues and merge requests ignored/declined in basically every open source project I've ever contributed to.

Reply on news.ycombinator.com