Shawn Walker wrote:
> I'm aware of the release binding concept. However, others seem to
> imply that before work can even begin on something, a formal proposal,
> etc. has to be done and something has to go through ARC.
> 
> I don't agree with that view.

I would too, which is why that is not what has *ever* been proposed.

What has been proposed is that the Project's interactions with the ARC
/begin/ at project creation time, and /conclude/ before the project
asks to integrate.  The "formal proposal" is nothing more than a bug
report, RFE or OS.o Project Instantiation Notice - certainly nothing
heavyweight like a functional spec or requirements document.

> A developer should be able to start work on something without getting

Agree 100%

> anyone's approval and only when they are ready to have their work
> reviewed (before integration into the main ON tree as an example)

The failure mode is waiting until you are done hacking before starting
the effort to understand the architectural impact of your work on the
rest of the community.

If you wait that long, you will have already (implicitly) committed
to a large set of architectural decisions, and it will be (de-facto)
way too late to change any of them.

> It should be up to the developer when they have to consult ARC, etc.

For simple projects that have no architectural impact (as determined
/by/ the developer), the sum total of ARC interaction is when the
developer self-determines that his or her project has no architectural
impact.  ~90% of the changes in a given product are completely self-
reviewed, and require absolutely no ARC interactions.

For the rest, 15 years of experience shows that early interactions
with the ARC lead directly to better projects; late interactions
find the /same/ issues, but by then the developer has too much
invested in their implementation to change.  The inevitable result
of late interaction with the ARC is frustration on both sides.

> A good developer will know when the right time to do that is.

Sadly, ~15 years of ARC experience shows that this is much harder to
do in practice than you imply.  Either that, or we don't have good
developers - a conclusion I'd disagree with strongly :-)

   -John




Reply via email to