Comment 2 for bug 1315796

Well, if you want to be a welcoming community, then you can't mandate the IDE either (I've written all my QML in gedit without auto-indent).

When I started writing Ubuntu apps, I was unsure what style to use, and couldn't find any style guides, which was annoying. Fortunately, I ended up with a style close to the one Bartosz linked. But, it would be nice to have found that when I first set out.

Consistent style makes a project easier to read and thus easier to maintain. Note the number one rule of PEP8 is consistency:
"A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important."

I've certainly written code in a non-standard (and sometimes uncomfortable) way to ensure the style is consistent with the project I was hacking on (like 8-width indents in nautilus, instead of spaces). Using my usual style would just make the code difficult to read as it doesn't fit in with the rest of the code.

I don't think it's too much to ask for people to have code follow a rough style that matches the project. Otherwise, you have contributors who add new features, then disappear. As the code gets more of these features in more and more differing styles, you get to the point where it becomes too difficult for the maintainers to understand the code and fix bugs. Getting frustrated, the maintainers may leave the project, and then you just end up with a mess of code with lots of bugs nobody's going to fix.

Maybe that seems a little extreme, but I can see that happening if you get lots of drive-by contributions in varying styles. Certainly, for my projects, I won't accept a merge proposal unless it fits the style of the project, or I'm willing to restructure the code myself before merging it (which I'll do if it's fairly well structured already).

In summary, I believe this is a choice between short-term gain and long-term gain. You can be open to everyone and accept any patch if it simply works, or you can think about the long-term contributors/maintainers that will be looking after your projects for years to come.

In the latter case, if a patch fails to match the style of the project, thank the contributor and then kindly ask them if they can restructure it to a consistent style before it's merged. Most contributors are excited to get their code accepted into a project, and will happily do this one little extra task. Maybe you'll lose a few contributions, but it's likely someone else will implement the same feature further down the line and get it accepted. In the long term, you should then have a more stable project with happier maintainers.