If you have a great idea to improve Snap!, then the first thing to do is open up a discussion on the forum.
THIS IS NOT an invitation do do so
Obviously, sometimes you might have the skills yourself to implement the idea and obviously you might want to code it up and try it out in your own fork.
And your idea may be great and your code may be great but ....
Almost no software project developer EVER likes an unsolicited bunch of suggested code improvements landing directly onto their project
Devs are usually concentrating on making their own (and merging code from other fully trusted sources) changes.
They don't have the time to look at your code
And despite your code being the best thing since sliced bread, they usually get quite irritated by the interruption
I'm not speaking for the Snap! devs - I'm just saying what things are like in 99.9% of cases.
This is general advice and not meant to dampen your enthusiasm - its intended to show a better way of maybe getting your good idea implemented
Just dumping from out of the blue will have the opposite effect
On a positive note, some great additions to Snap! have come from the process of talking about it on the forum first.
Some have led to the Snap! team directly changing Snap! - some have led to to to a request for a PR
This is meant as good, friendly advice that will serve young coders well on their software development journey
I think this is an overgeneralization. Snap! is basically a one-author labor of love. I think what would make Jens happiest is if he wrote every line of code himself. :~) (But Snap! has (imho) gotten too big for that.) So that's Snap! 's policy.
But a lot of widely used software, and especially the really complicated programs such as the Linux kernel, is built as wide-scale collaborations. Everyone is invited to contribute, although most contributors have their work checked by someone else.
Wikipedia has made it clear to the whole world (apart from a few schoolteachers, sigh) how even a politically charged body of text can be written by unmoderated contributors, with reversions by other volunteers in the rare cases of vandalism. You can even look up Palestine and get an impressively disinterested result. (Maybe that's an unfair example because that article is one of the few protected from unmoderated edits. But still, volunteers decide that.)
And it's that much easier with code, which is generally not sensitive politically, although sometimes it happens, e.g., when there's a copyright issue.
On wide-scale collaborations such as Linux, people can get banned from contributing if their contributions are always rejected by moderators for the same reasons, and they don't learn anything from the rejections. That's what you want not to do, in the wide world of software development. But if a project has a public git repository, it's a collaboration, anyone can fork it, and sometimes people are welcome to make PRs. Each project is different. Read the README in the repo, and the CONTRIBUTING if there is one.
