Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
To: dev@forrest.apache.org
From: "Scherler, Thorsten" <thorsten@apache.org>
Subject: Re: [DRAFT] Forrest Project Guidelines
Date: Thu, 01 Jul 2004 20:04:08 +0200
Lines: 138
Message-ID: <cc1ji4$t3n$1@sea.gmane.org>
References: <1086761689.31520.41527.camel@ighp> <ca6di8$tpd$1@sea.gmane.org>
 <1086772558.31520.42264.camel@ighp>  <ca6lmc$icg$1@sea.gmane.org>
 <1086787587.31519.43797.camel@ighp>  <ca76cj$8hj$1@sea.gmane.org>
 <1087619052.1555.68.camel@ighp>  <1088303182.18566.10185.camel@ighp>
 <1088598159.18566.46238.camel@ighp>
 <DD242D36-CAA8-11D8-AF18-00039385397E@medata.com>
 <cc0oau$hur$2@sea.gmane.org> <Pine.LNX.4.58.0407010803140.29818@ferrari>
 <cc15pl$n4i$1@sea.gmane.org> <Pine.LNX.4.58.0407011027310.11936@ferrari>
 <cc18ne$vp2$1@sea.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.4) Gecko/20030612
In-Reply-To: <cc18ne$vp2$1@sea.gmane.org>
Sender: news <news@sea.gmane.org>

Nicola Ken Barozzi wrote:

> Dave Brondsema wrote:
> 
> ...
> 
>> That explanation helped.  
> 
> 
> :-)
> 
>> What about this: committers cannot vote, unless
>> they are a PMC member.  After the committer demonstrates he/she can work
>> well with us, we can propose they join the PMC.  The only people who stay
>> "just committers" would be most Lenya & Cocoon committers and
>> task-oriented committers who don't want to be more involved.
>>
>> This keeps the committing roles to 2 instead of 3.
> 
> 
> This is what I was proposing...
> 
> I'll have to update the voting doc to reflect this:
> http://incubator.apache.org/learn/voting.html
> 
> The notion of "developer" is not something we normally use, but that is 
> defined.
> 
> http://www.apache.org/foundation/roles.html
> 
> These are users
> 
>  - User (that are on the user list)
>  - Developer (that are on the dev list,
>               we usually still call them users, as our users are
>               mostly also developers)
> 
> These are committers (*):
> 
>  - Committer (non core group)

>  - PMC member (core group that can vote)
> 

For me following the thread I do not see the need for more roles but 
more to define the procedures for the project clearer.

In terms of strategic management a strategy can be formulated on three 
different levels [2]:
* corporate level
[2] Corporate level strategy fundamentally is concerned with the 
selection of businesses in which the company should compete and with the 
development and coordination of that portfolio of businesses.
[1] The Project Management Committee (PMC) is a group of committers who 
take responsibility for the long-term direction of the projects in their 
area.

* business unit level
[2]At the business unit level, the strategic issues are less about the 
coordination of operating units and more about developing and sustaining 
a competitive advantage for the goods and services that are produced.
[1]Frequent and valuable contributers to a project are granted write 
access to the source code repository. These committers are the people 
who make the day-to-day decisions about what changes will be made to the 
software.

* functional or departmental level
[1]The strategic issues at the functional level are related to business 
processes and the value chain. Functional level strategies in marketing, 
finance, operations, human resources, and R&D involve the development 
and coordination of resources through which business unit level 
strategies can be executed efficiently and effectively.
[2]A user who contributes to a project in the form of code or 
documentation becomes a developer. Developers usually subscribe to the 
project development mailing list and contribute by sending patches to 
the list.

I see user more as the client of a traditional company. The goal of a 
strategy is to define a set of rules to competing and surviving in the 
market.

Like a company wants to create a good product with the help of the right 
strategy to get new or keep the loyal customer. Forrest tries to create 
a good software product and the loyal user are telling us what they like 
and what not.

[1] The most important participants are the people who use our software. 
The majority of our developers start out as users and guide their 
development efforts from the user's perspective.

In my opion everybody has the right to vote on a subject as an 
expression of *his/her* *personal* *opinion* about it. We can 
differentiate between binding and non-binding votes. We can further 
define the strategic level of the topic to define when a vote have 
binding power:
* corporate level - PMC
* business unit level - committer
* functional or departmental level - dev

Then we can go ahead and use the nice voting mechanism from 
commons-httpclient-dev@jakarta.apache.org
------------------------------------------------------------------------
   Vote:  TOPIC OF VOTE
   [ ] +1 I am in favor of the release, and will help support it.
   [ ] +0 I am in favor of the release, but am unable to help support it.
   [ ] -0 I am not in favor of the release.
   [ ] -1 I am against this proposal (must include a reason).

------------------------------------------------------------------------

This would give information to manage the project because more or less 
we will know where our ressources are.

my 0.02�

king regards
thorsten

[1]http://www.apache.org/foundation/roles.html
[2]http://www.quickmba.com/strategy/levels/

-- 
<thorsten>
  <name>Thorsten Scherler</name>
  <country>Spain</country>
  <@mail>thorsten.at.apache.org</@mail>
 
<@cocoon-WIKI>http://wiki.cocoondev.org/Wiki.jsp?page=Scherler</@cocoon-WIKI>
  <http>http://www.target-x.de</http>
  <acronymfinder>http://www.acronymfinder.com</acronymfinder>
  <motto>
	"My task which I am trying to achieve is,
	by the power of the written word,
	[...] to make you see."
	*Joseph Conrad (1857-1924)*
  </motto>
</thorsten>