Before getting into specifics about how AOO practices fit ASF Principles, it 
may be useful to consider that there is a hierarchy from principles to policies 
to practices.  It is useful to consider how exceptions arise and are put into 
practice too.

 - Dennis

PRINCIPLES ABOVE POLICIES

For this discussion, it is useful to consider principles as a fundamental 
source and foundation of chains of reasoning about policies and then practices 
that then conform to those policies.  Principles are behind what we do that 
matters.  There is room for arbitrariness where no principle is contradicted 
and there may be many ways to provide policies that are consistent with the 
essential principles.  Consider principles to be abstract and high-level with 
policies being (more) specific and narrowing.

It is often the case that one senses principles in the background of the 
policies that are announced and enacted.  Do not expect sharp boundaries.  

The greatest principle is in the mission of the Apache Software Foundation 
(ASF) to provide software for the public good 
(<http://www.apache.org/foundation/>).  How the ASF has declared itself to 
operate in the public interest in providing such software is the context for 
its principles and policies.

A great place to see the kinds of principled approaches applicable to Apache 
Projects is the "Maturity Model for Apache Projects", 
<http://community.apache.org/apache-way/apache-project-maturity-model.html>.  

You can see the mix around degrees of specificity there.  There are principles 
about what one would be able to observe about a given Apache Project, without 
specifying the details about what would be observed.  There are some quite 
specific policies.

Examples:
  Items CD10-CD50 do not say how those qualities of code are achieved and 
demonstrable.  One can perceive these as principles leaving it up to other 
policies and project practices to demonstrate their satisfaction.
  Item LC10 about releases being under the Apache License, version 2.0, is a 
specific policy.
  It is useful to explore all of these items from CD10 (on code) to IN20 (on 
contributors acting as themselves and not as members of organizations).

There is more about principles to be found in 

 * "How the ASF Works", <http://apache.org/foundation/how-it-works.html>, with 
some varying detail.  Review the role of Project Management Committees (PMC) 
under "Foundation Structure."  Review the "Project Management and 
Collaboration" section, especially the principled "Philosophy" subsection.

 * The "Getting Started for Contributors" page, 
<http://community.apache.org/contributors/> has more information about this and 
the "Project Independence" section links to specific policies and practices.

PRACTICES AND EXCEPTIONS

There are many practices that support how the ASF pursues its mission.  The use 
of mailing lists is one example.  The use of services supported on Apache 
infrastructure is another.

There can be exceptions to policy and deviations among practices.  Exceptions 
tend to be very specific and not generalized.  (I suspect a generalization 
would be a change/amendment of policy and a serious review of any conflicts 
with established principles.)

An example of an exception that is specific to the Apache OpenOffice project is 
the distribution of convenience binaries that have writing-aid plug-ins bundled 
with them that are not themselves under a license that is acceptable for 
source-code releases.  There are a number of specific, delimited provisions 
under which this action is found consistent with Apache principles although it 
is an exception to a general policy.  This practice was only introduced after 
obtaining review and eventual concurrence via the list on which legal and 
license questions are discussed.

Finally, it is important to understand the community focus and information 
about it, <http://community.apache.org/>.  Conduct of projects is highly 
decentralized and projects have considerable freedom and variation *so long as* 
the prevailing principles, policies, and related processes are honored.  
Exceptions must be very narrowly and specifically defined and do require 
pre-approval.  It is valuable to find a way to operate without any exceptions.  
That will come up when specific opportunities for cooperation and collaboration 
are considered.

-----Original Message-----
From: Dennis E. Hamilton [mailto:orc...@apache.org] 
Sent: Thursday, June 25, 2015 13:58
To: dev@openoffice.apache.org
Subject: AOO Principles for Cooperation among ODF Projects

[ ... ]

I want to address what the aspirations of the Apache Software Foundation (ASF) 
are in terms of its principles and policies, and how they arise in the 
character of Apache projects.  When I appeal to principles that are bedrock for 
the Apache Software Foundation, I will provide references and locations where 
those are presented and discussed already.

The idea is to identify fundamental principles behind the framework which AOO 
and all ASF Projects operate within and which cooperative activities are 
expected to be consistent with.  The idea is to use that as a basis for 
exploring and bootstrapping some actual cooperative activities.

Here's what I see in a progression of discussions about principles and areas 
for action.

 1. The ASF Principles on how code of others is accepted into ASF Projects and 
how it is respected.

[ ... ]


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Reply via email to