> In particular, there are people who have patches for svn, and we don't > handle them very well. In some cases, there is a high bar of > review/change/resubmit that turns people off. In other cases, people > are focused on whatever task they're working on, and the patches are > left by the wayside. We have a Patch Manager that attempts to ensure > we don't completely lose patches, but that is a far cry from > *engaging* those patch developers. In other scenarios, we have several > people all providing "input" and "direction" to the would-be > patch-provider. That incoherency and pulls in different directions can > also turn off potential contributors.
I wonder if the maillist method of patches and reviews is just to brittle. Is there any consideration to using a code review tool... perhaps review board or something else. This way the submitting and management of patches is more centralized than the disjointed threads on a mail list. > We talked about these issues, and how we could provide "mentors" to > work with people that arrive with patches. A person would be volunteer > to work with the patcher, and provide a single point of > contact/review. That sounds like a good idea... but it also disrupts the distributed nature of an open source team. That mentor may get hung up with real life work or be unavailable, or in a different time zone...etc. > Of course, do we have enough people willing and able to fill that > role? (if that is even the best way!) Oh yea... what I just said... you said too. BOb
