The importance of defaults

[Patrick Lightbody <fo...@opensymphony.com>]

Related to the ! thread, but a more general concept that I want to bring up and underscore. This is my mini manifesto on why we can't treat the default options and settings in Struts lightly. These are all my opinions, but I think they are also fairly common sense.

Goal: It should be our goal to ship Struts in a way that it is pre-configured with default settings that mimic the agreed upon styles and techniques by the very best Struts users and developers.

This is critically important. Suppose we ship struts with all sorts of options turned off by default, but the core set of developers turn those options off in all our apps. What will happen is that the user base, who generally will not change the defaults, will use Struts under different constraints than the developers. A disconnected will form, and the users will push for changes that the developers will not understand or see in their daily development. 

We should tread very carefully whenever we talk about options and switches and say, "well don't worry, they can turn it on if they want". If every developer is in agreement, then it is fine. But if, say, Ted or Don or Patrick doesn't agree, we need to really dig in to the heart of the issue. Because odds are that what is happening is that two very different styles of development are happening by different team members, and therefore the product isn't being optimized due to competing interests.
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=41361&messageID=82485#82485


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Proposal: Start the Struts 2.1 branch (was Re: The importance of defaults)

[Don Brown <mr...@twdata.org>]

Fine - I propose the branch be named "Able".

Don

Ted Husted wrote:
> +1
>
> But let's not label it the "2.1" branch. Last I knew, we observed the
> Rules for Revolutionaries
>
> * http://incubator.apache.org/learn/rules-for-revolutionaries.html
>
> which says that we should name the branch first, and then decide
> whether to accept it, or what version to assign, once there is actual
> code on the table.
>
> -Ted.
>
> On 8/25/06, Don Brown <mr...@twdata.org> wrote:
>> I agree to a degree, however, it is inevitable that a lot of resources
>> that would be used in moving the code forward are absorbed by these
>> "discussions", and generally, the folks with the energy and vision to
>> move forward don't have the patience for drawn out detail discussions.
>>
>> While ideally, there is a healthy balance between diversity and unity of
>> vision, I feel the Struts community is leaning too much towards
>> diversity lately with little unity of vision.  The problem is we don't
>> seem to have a shared vision of what Struts 2 is and should be, and we
>> need that shared vision to guide our discussions and propel innovation.
>>
>> When we started the Struts Ti proposal, we did so with the vision of a
>> framework that makes development easier, requires no configuration, and
>> had support for advanced flow management features.  If that is still the
>> desired goal, then I think Patrick's Able extensions is our best bet to
>> realizing it.  In fact, it was from working closely with Patrick in
>> implementing the first versions of Ti that prompted the closer
>> collaboration movements, culminating in Ted's proposal to combine
>> efforts completely.
>>
>> Should Able go into the code base now?  No, I think we should take what
>> we have, get it stable, and get it out there to our users.  However, we
>> shouldn't wait to start realizing the Ti vision, so I propose we start
>> the Struts 2.1 branch in Subversion, and seed it with Able.  Let 2.1 be
>> a breeding ground for innovative, convention-based code.  We need to
>> foster continued, forward-looking development, while stabilizing what we
>> have today.
>>
>> Don
>>
>> Ted Husted wrote:
>> > But, we are the user base too. In practice, a PMC is a working focus
>> > group. Hopefully, we will attract developers from a wide variety of
>> > projects, so that the framework we build will be robust enough to fill
>> > all our varied needs.
>> >
>> > Personally, I think it's a good thing that Patrick writes applications
>> > one way and that Jason writes them a different way. The differences
>> > are our strength. The differences are what make the framework worth
>> > the time and effort it takes to build it.
>> >
>> > -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Proposal: Start the Struts 2.1 branch (was Re: The importance of defaults)

[Ted Husted <hu...@apache.org>]

+1

But let's not label it the "2.1" branch. Last I knew, we observed the
Rules for Revolutionaries

* http://incubator.apache.org/learn/rules-for-revolutionaries.html

which says that we should name the branch first, and then decide
whether to accept it, or what version to assign, once there is actual
code on the table.

-Ted.

On 8/25/06, Don Brown <mr...@twdata.org> wrote:
> I agree to a degree, however, it is inevitable that a lot of resources
> that would be used in moving the code forward are absorbed by these
> "discussions", and generally, the folks with the energy and vision to
> move forward don't have the patience for drawn out detail discussions.
>
> While ideally, there is a healthy balance between diversity and unity of
> vision, I feel the Struts community is leaning too much towards
> diversity lately with little unity of vision.  The problem is we don't
> seem to have a shared vision of what Struts 2 is and should be, and we
> need that shared vision to guide our discussions and propel innovation.
>
> When we started the Struts Ti proposal, we did so with the vision of a
> framework that makes development easier, requires no configuration, and
> had support for advanced flow management features.  If that is still the
> desired goal, then I think Patrick's Able extensions is our best bet to
> realizing it.  In fact, it was from working closely with Patrick in
> implementing the first versions of Ti that prompted the closer
> collaboration movements, culminating in Ted's proposal to combine
> efforts completely.
>
> Should Able go into the code base now?  No, I think we should take what
> we have, get it stable, and get it out there to our users.  However, we
> shouldn't wait to start realizing the Ti vision, so I propose we start
> the Struts 2.1 branch in Subversion, and seed it with Able.  Let 2.1 be
> a breeding ground for innovative, convention-based code.  We need to
> foster continued, forward-looking development, while stabilizing what we
> have today.
>
> Don
>
> Ted Husted wrote:
> > But, we are the user base too. In practice, a PMC is a working focus
> > group. Hopefully, we will attract developers from a wide variety of
> > projects, so that the framework we build will be robust enough to fill
> > all our varied needs.
> >
> > Personally, I think it's a good thing that Patrick writes applications
> > one way and that Jason writes them a different way. The differences
> > are our strength. The differences are what make the framework worth
> > the time and effort it takes to build it.
> >
> > -Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Proposal: Start the Struts 2.1 branch (was Re: The importance of defaults)

[Don Brown <mr...@twdata.org>]

I agree to a degree, however, it is inevitable that a lot of resources 
that would be used in moving the code forward are absorbed by these 
"discussions", and generally, the folks with the energy and vision to 
move forward don't have the patience for drawn out detail discussions.

While ideally, there is a healthy balance between diversity and unity of 
vision, I feel the Struts community is leaning too much towards 
diversity lately with little unity of vision.  The problem is we don't 
seem to have a shared vision of what Struts 2 is and should be, and we 
need that shared vision to guide our discussions and propel innovation.

When we started the Struts Ti proposal, we did so with the vision of a 
framework that makes development easier, requires no configuration, and 
had support for advanced flow management features.  If that is still the 
desired goal, then I think Patrick's Able extensions is our best bet to 
realizing it.  In fact, it was from working closely with Patrick in 
implementing the first versions of Ti that prompted the closer 
collaboration movements, culminating in Ted's proposal to combine 
efforts completely.

Should Able go into the code base now?  No, I think we should take what 
we have, get it stable, and get it out there to our users.  However, we 
shouldn't wait to start realizing the Ti vision, so I propose we start 
the Struts 2.1 branch in Subversion, and seed it with Able.  Let 2.1 be 
a breeding ground for innovative, convention-based code.  We need to 
foster continued, forward-looking development, while stabilizing what we 
have today.

Don

Ted Husted wrote:
> But, we are the user base too. In practice, a PMC is a working focus
> group. Hopefully, we will attract developers from a wide variety of
> projects, so that the framework we build will be robust enough to fill
> all our varied needs.
>
> Personally, I think it's a good thing that Patrick writes applications
> one way and that Jason writes them a different way. The differences
> are our strength. The differences are what make the framework worth
> the time and effort it takes to build it.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: The importance of defaults

[Ted Husted <hu...@apache.org>]

On 8/25/06, Patrick Lightbody <fo...@opensymphony.com> wrote:
> Goal: It should be our goal to ship Struts in a way that it is pre-configured with default
>settings that mimic the agreed upon styles and techniques by the very
best Struts users
>and developers.

Hmmm, how do we determine who are the "very best" developers. I meet a
lot of excellent developers in the field. I'm sure some of them are
better Struts developers than I am. In fact, they are so busy being
excellent Struts developers, they don't have time for this sort of
thing :)

Personally, I wouldn't characterize the PMC as the "leaders" or the
"best of breed". The PMC is simply a group of individuals who are
willing to contribute to the project and share a common set of values
regarding collaboration. We are willing to work together to create and
maintain the framework that we want to use to build our own
applications.


>  But if, say, Ted or Don or Patrick doesn't agree, we need to really dig in to the heart of
> the issue. Because odds are that what is happening is that two very different styles of
> development are happening by different team members, and therefore the product isn't
> being optimized due to competing interests.

A PMC with diverse interests is the core strength of an ASF project.
Even if the indivduals on the PMC were to agree on a large set of best
practices, that doesn't mean we will get to use all of those practices
at our day jobs. Ideally, we will be among the developers that need to
change some of the defaults to meet the needs of our own projects. We
are all working developers, and we eat our own dog food.

> This is critically important. Suppose we ship struts with all sorts of options turned off by
>default, but the core set of developers turn those options off in all
our apps. What will
>happen is that the user base, who generally will not change the
defaults, will use Struts
>under different constraints than the developers. A disconnected will
form, and the users
>will push for changes that the developers will not understand or see
in their daily
>development.

But, we are the user base too. In practice, a PMC is a working focus
group. Hopefully, we will attract developers from a wide variety of
projects, so that the framework we build will be robust enough to fill
all our varied needs.

Personally, I think it's a good thing that Patrick writes applications
one way and that Jason writes them a different way. The differences
are our strength. The differences are what make the framework worth
the time and effort it takes to build it.

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org