Thanks for the comments everyone!
This is a really good point. The thing which I want to try and promote is that everyone works in the open so that anyone else can contribute and give feedback. Since MusicBrainz is a very open project I wanted to encourage that also in the development of AcousticBrainz. I agree that we shouldn't stop anyone from working on a project personally and then presenting it to the community, but people who are working on AB in an "official" capacity (e.g., SoC students or MeB employees) should be planning and developing in the open. How can we describe this better?
Yes, I think so. I said this in the Development section (always work on a feature branch). I want a little bit of flexibility especially for emergency bug fixes, though.
Good point. How can we keep them small? Either start the PR before it's finished so that we can start discussion, or break the code into small parts. I don't have a problem with having multiple PRs per jira ticket if it can be split up into small parts
This comes back to the point about main developers being open about the work that they are doing. Again, we shouldn't stop someone from submitting a PR where they add some extra functionality, or fix some spelling, however if someone comes to us and says "I'm interested in working on a feature which does x", the first thing we should try and do is get a record of it so that we can start discussing it.
I agree. I don't think we need to squash before merge, unless the PR author wants to do that as a last step. Perhaps if they're working on a branch they can squash before they make the PR. I sometimes rebase/squash branches, but perhaps we could decide to stop this behaviour.
Right. I also would argue that you can make this with a
git log, though it may be a little more difficult. What I was getting at by making this suggestion was that it would keep everyone else more up to date with exactly what everyone else is working on.