Maciej Szefler wrote:
In general I'd prefer less discussion rather than more, applying the
following rules:
1. deviations that get us closer to an established goal do not require
discussion
Let's not forget that friendly courtesy notices are always appreciated :)
2. ditto for refactors / improvements of existing functionality
As long as test cases continue to work! And bonus points are awarded
for new test cases covering new/existing functionality.
3. new core features where there may be disagreement as to the
requirements require some discussion beforehand.
4. non-core features should not require discussion unless they are found
be a nuisance or until it is determined that they are in fact core
features.
I think there are some subtleties and nuances that can be applied here.
Without going into details let's just say that I believe more
communication is better than less communication... assuming, of course,
a good signal-to-noise ratio!
All these are subjective of course. If something more rigid is called
for then we might consider establishing ownership responsibilities for
certain areas of the project so that we don't have to get bogged down in
endless discussions. Of course there would always be recourse to
democracy: if for example there is a big disagreement that cannot be
worked out between someone working on the engine, and the API owner,
then this nuclear option is always available.
I'd be interested to hear our mentors on this subject.
My understanding of the Apache meritocracy is that you don't really want
to assign "owners" to areas. People who actually contribute, maintain
and support specific areas become owners as a matter of act, not
attribution. In that sense, ownership is not an inherent right but
rather a privilege that is implicitly and temporarily granted based on
the work being done and its value to the community. We should always
seek consensus but in difficult situations, actions speak louder than words.
cheers,
alex
