I've had the honor to join other experienced FOSS hackers on the Jury for the Hackontest. The idea was to let the community collect a number of work-items for teams (of 3 developers) working on a particular project, then pick some of those work items and see how far each team gets within 24 hours.
I think it was a very interesting concept. Something that at least I have not yet seen anywhere else before. The organizers did a great job with the preparation. Setting up the website for project proposals, collecting community votes on the individual tasks, putting together the jury.
The participants of the contest then were placed into a container (yes, the kind of containers used for international shipping) with a fridge, beer, snacks, Internet, power, a projector and some other gear. They had vnc running on all of their systems, to enable a large public screen at the trade show where people would be able to follow whatever happens on-screen right now on a system of a random developer participating in the context. 'reality-tv for hackers' ;)
The results and the progress were quite different between the individual projects. I don't want to reveal the internal discussions we had in the jury, but one thing that basically everyone agreed to was the improper use of revision control systems. None of the teams was setting a good example on how to use them. Either the granularity of the commits, or the changelog texts, or the time when they committed was wrong. You shouldn't commit unrelated changes, never do cosmetic and functional changes in one commit, etc. This is what makes your work reproducible, readable and understandable to others, like the jury and particularly your own user and developer community. It is one aspect that affects a lot how easy it is for others to contribute to your project or to contribute to it.