Is there a method to sponsor specific GNOME changes to be included in a future release.
General:
There is a strong feeling amongst many GNOME users that feedback is ignored. There is some evidence of this in recent history. I understand that collecting, filtering, and managing feedback is very difficult, and decisions have to be made. So I want to “pay for the product”, so to speak. Donating or becoming a “Friend of GNOME” doesn’t sound like it will make my feedback any more relevant. I want to be able to sponsor specific development since I don’t have the skill level to contribute myself.
Specific:
I dislike the change to to primary-paste, but I can accept the change to the default. I strongly dislike the fact that the setting to restore functionality is “hidden” behind gsettings, dconf-editor, or tweaks.
I want to sponsor development to add the setting to the primary Settings application.
As a general rule: no. The Foundation, which is the legal entity that would receive the donation, is a registered non-profit which cannot receive donated money and provide specific services. On top of that, the Foundation is not responsible for the technical direction of the GNOME project.
The only thing the Foundation can do is sponsor the GNOME project, or developers affiliated with the project, but it cannot direct them to do things.
This is precisely what the Foundation cannot do, lest it loses the non-profit status.
You can reach out to some developer and designer that can work on it, but you have no guarantee that the change will be integrated.
Problem with this is that middle click paste drama was fully overblown and abusive. It’s very hard to take feedback seriously from people who refuse to look further than their own nose. You can read that whole thread and please tell me, do you genuinely think such “feedback” would convince you?
And one big thing here: even if some developers rejects community suggestion it doesn’t mean the user feedback is ignored. Trust me, it’s not how general thought process works here in GNOME.
Thanks for responding, and so quickly.
It’s interesting that it’s coming from you, since it’s your own advice I’m trying to follow.
“The only way for you to have actual influence in the decision making process is to become a GNOME developer.”
Since spamming a list of developers with a request to do some work feels invasive and rude. Is there a GNOME mailing list that might accept a bug bounty like this? I’m trying to get involved without offending people, or spending 6 months digging through communications/commit logs to understand the community culture. I am looking for advice.
If you’re serious about it, I recommend joining Matrix (if you’re not already there) Matrix - GNOME Project Handbook and join #design:gnome.org room and ask designers if they’re fine with it. If you hear an OK response, you can then start with planning. GNOME doesn’t have mailing lists anymore and there is no bug bounty. You would have to yourself find people and ask if they’re interested. You could join Settings room on matrix (after you ask designers) if someone would be interested in a job. Keep in mind I’m not a lawyer, you will probably pay taxes or something.
Whoa, slow down. I’m not looking to start that argument back up, I did read the entire thread multiple times actually.
I was not part of that and your response is starting to scare me off completely.
There were some rude comments in that thread, but there were many others that were just expressing feedback politely, let’s not paint them all with the same brush.
Sorry, I am not trying to scare you off or anything, but ebassi’s message you linked was talking about exactly those type of people. And we got thrown A LOT OF shit, so while there could have been nice people there (i honestly dont remember that thread), there were also tons of trolls and bad faith actors. That wasn’t a nice experience for us.
I understand, textual communication is hard in general which can cause misunderstandings easily. Add to that a couple of intentionally bad actors, and I can understand that it felt horrible and that you were being attacked. I’m sorry that whole thing happened.
On the other side, those users seemed to feel their feedback was dismissed and not valued, both the rude and polite commenters. I felt that way myself after reading some of ebassi’s comments. I guess the difference is that I started this thread to follow his stated advice. To be honest with myself, partly through “malicious compliance” since my feelings were hurt.
Though as I was researching the donation details and rereading the comments in the thread more carefully, trying to read the best of intentions into each comment possible. I came away with the opinion that feedback is hard on both sides (giver and receiver). Givers were frustrated and felt ignored, receivers felt attacked. And the feelings of each were leading to worse communication in both directions. So I added a second motivation to this post, honest attempt to work with a bad system of feedback collection to make good changes.
Thank you for the advice on how to contribute in another way.
Developers are weird. We’ll do a task that interests us for free, but a task that doesn’t interest us will be expensive. You only need bounties for the tasks that don’t interest us; therefore, you’re going to need a moderately high amount of money to attract a developer to a bounty. We used to use Bountysource for bounties, but that was quite unsuccessful. People would post maybe $100 for a bounty, but developers are unlikely to work for that amount.
Your specific objective in this case is controversial, which makes everything much harder. The bar for adding settings to gnome-control-center is simply rather high.
In this case: adding a toggle somewhere is trivial for a developer, so your actual challenge is going to be convincing designers that the setting should be user-visible, and where specifically it should go. This might be impossible. If you can manage that successfully, almost certainly some developer will be willing to submit a merge request for free. So a bounty doesn’t seem like a good fit for this issue.
Silver lining: even if you fail in this particular goal, the middle click paste feature will probably live on behind that hidden setting indefinitely, and possibly forever.
Letting a single person decide on features in GNOME, just because they have money, would be one of the worst ideas for the project. If I look at the “feedback” that I have “ignored,” it quickly turns out that many of these requests are plainly contradictive. There is just no way to design software for millions of people by following the ideas of every single person that has an opinion.
@ebassi ElementaryOS, non-profit organization, used to offer developer bounties and it didn’t break their non-profit status, although I can’t speak of the legal details and I understand this is a complicated matter.
But this is how it worked: every issue in the repository had a “Offer bounty” button in which individuals - not eOS - would offer money in exchange of completing certain issues. When the issue would be completed, that money would be sent to the developer who did the work.
No money is going to the non-profit, it’s going from individuals to individuals.
@sophieherold I understand that involving money can introduce certain biases, and I agree we shouldn’t prioritize an issue just because someone is paying for it. In this system that I propose, whether a feature gets merged would not depend on who pays the most money. The money is there to incentivize that the feature is developed. Whether it’s merged afterwards? That’s decided by the maintainers, exclusively, like always.
The only difference with this system is that issues that aren’t satisfactory to do, but need to be done, don’t stay uncompleted for large periods of time, because there is a monetary incentive. Quality assurance doesn’t deteriorate.
Personally I don’t agree 100% with this system because, for me, it breaks the Open Source communist ideal of people working for the benefit of others & not for profit. But maybe it could work? It’s rare for normal people to pay for a feature request. In reality, only the people who are:
a) Very invested into the project
b) Have a lot of money
c) Organizations with a very urgent issue they need fixed
end up paying. But maybe this could make it easier for non-programmers to influence the outcome of the project. I am thinking of UX improvements.
Let me speak authoritatively, then, as a former director of the board of the GNOME Foundation: if you donate to the Foundation and your donation comes with the string attached of getting something out of it, then the Foundation will have to reject your donation. That’s the way 501(c)3 non-profits have to work.
That’s another thing entirely, since it bypasses the Foundation. It’s also entirely on you to do this, and you have to realise that the project maintainers are also entirely within their rights to reject any such contribution that you sponsored.
Did I miss something? AFAIK ElementaryOS is no legal entity and instead run by elementary, Inc. a for-profit company. But maybe you can point me to the organization you mean.
Let me add one more lens to this. Usually, what I tell people who feel the way you do - I try to explain that features, bugs, or abstract issues has to be coached in the mission. For instance, for design issues I always try to align it against “distraction free computing”. I almost always get people willing to listen when I write a bug report or feature request coached in the language how it might violate a organizing principal. For instance, I frequently get annoyed that I can’t find my mouse pointer on large monitors. For me it violates “distraction free computing” - it’s hard to get work going when I can figure out where my mouse is! I haven’t put in a bug yet because I’m trying to coach it in a language that designers might believe that is an actual problem.
GNOME gets a lot of feature requests or requests to revert a behavior. Every feature or behavior comes down around an underlying organizing principal. Sometimes, when something gets removed there is a good reason for it - resources, technical complexity/maintenance cost, or that makes no sense.
For your specific case, I understand that bluefin still lets you use the old method of two clipboard sources. So some downstreams might be willing to keep a certain behavior for historical reasons and maintain that.
A more radical approach would be to fork gnome-build-meta, add the changes you want (or pay for them) and then roll your own GNOME OS with those changes (but with a different branding/name/trademark) and you can share that with others. As long as you adhere to the GPL license you’re golden.
This is still a free software project, and we love software freedom. You should be able to do what you like with GNOME and change it however you like but that doesn’t mean that the upstream developers must bear the price of maintenance of your changes unless they agree by accepting their MR.
