Merge pull request #9 from rjschwei/upWorkflowDescr

workflow updates

two +1

Author: rjschwei

README.md

@@ -9,51 +9,47 @@ umbrella of the Linux Foundation.
 For many years the working group has spent its time focusing on the
 production of the LSB specification which consists of a formal written
 specification, similar to IEEE or ISO standards, and an accompanying test
-suite.
+suite. The test suite was focused on certification testing of distributions
+and as such had an easy to use LSB specific test framework.
 
 The specification was historically defined as a 'trailing' specification 
-to document an
-accepted cross section of packages, libraries, and interfaces in Linux
-distributions. As the Linux distribution development process has matured, 
-in recent years this become a primary focus on the Enterprise distributions,
-as so called bleeding development happens in distributions less interested 
-in long term stability, and more interested in living at HEAD and in 
-continual development. 
+to document an accepted cross section of packages, libraries, and interfaces
+in Linux distributions. Linux distribution development happens at various
+rates ranging from a 6 month release cycle at the short end to multi year
+release cycles at the long end of the time scale. Distributions with the
+longer release cycle are generally more interested in long term stability
+and as such had become the primary target of the LSB specification.
 
-As the commercial 
-"Linux market" has matured the specification and tests have contributed to
-maintaining a certain compatibility across Linux distributions making it
-reasonably straight forward for ISVs to treat many distributions as one
-Linux platform. At the same time 
-with the market acceptance and adoption of Open Source software, 
-and the Agile rapid development models, and Test Driven Design, 
-a demand has appeared for new interfaces.  The speed
-at which these interfaces have been adopted by Linux distributions has
-significantly increased such that the creation of a formal specification
+As the commercial "Linux market" has matured the specification and tests
+have contributed to maintaining a certain compatibility across Linux
+distributions making it reasonably straight forward for ISVs to treat many
+distributions as one Linux platform. At the same time with the market
+acceptance and adoption of Open Source software, Agile rapid development
+models, and Test Driven Design, a demand has appeared for new interfaces.
+The speed at which these interfaces have been adopted by Linux distributions
+has significantly increased such that the creation of a formal specification
 and accompanying certification is no longer as important a primary goal. 
 
-Therefore,
-at the face to face meeting held during the Linux Foundation Collaboration
-Summit in March, 2014, the working group has concluded that rather than
-producing a voluminous specification, the working group should transform its
-work to emphasize its other role as a neutral venue to discuss and resolve cross-distribution topics
-that are important to ISVs and distributors. This new focus will allow the
-working group to continue to provide the value of contributing to distribution
-compatibility while at the same time being more involved in cross-distribution
-discussions.
+Therefore, at the face to face meeting held during the Linux Foundation
+Collaboration Summit in March, 2014, the working group has concluded that
+rather than producing a voluminous specification, the working group should
+transform its work to emphasize its other role as a neutral venue to discuss
+and resolve cross-distribution topics that are important to ISVs and
+distributors. This new focus will allow the working group to continue to
+provide the value of contributing to distribution compatibility while at the
+same time being more involved in cross-distribution discussions.
 
 The LSB 5.0 specification released in 2014 may well be the last of 
-its kind. The
-specification and tests are in maintenance mode. Bugs will be accepted and
-fixed and these bug fixes may be released as updates, i.e. 5.0.1 and others
-as needed. However, we do not presently plan to work to produce a new 
-LSB 5.1 or 6.0
-specification. The specification and accompanying tests remain in the Bazaar
+its kind. The specification and tests are in maintenance mode. Bugs will be
+accepted and fixed and these bug fixes may be released as updates,
+i.e. 5.0.1 and others as needed. However, we do not presently plan to work
+new major LSB specification releases such as LSB 5.1 or 6.0.
+The specification and accompanying tests remain in the Bazaar
 tree ( http://bzr.linuxfoundation.org/loggerhead/lsb/ ) maintained by the
 working group. No new development, i.e. large scale addition of new 
-interfaces, libraries,
-etc., is expected in the Bazaar repository.  That repository will be quiesced 
-as to new commits, and parts may be replicated over into a 'git' backing store.
+interfaces, libraries, etc., is expected in the Bazaar repository.  That
+repository will be quiesced as to new commits, and parts may be replicated
+to the GitHub Linux Standard Base project.
 
 The focus on providing distribution compatibility, where it matters to
 distributions, ISVs, and other stakeholders will remain a key goal of the
@@ -62,24 +58,28 @@ challenge will be described in a reasonably short document along with a
 solution. Once a solution is accepted by a number of distributions it becomes
 a de facto standard. Where ever possible one or more tests are to be
 implemented that allow distributions to test their compliance to the agreed
-upon specification.
+upon specification. Distributions that pledge to support the agreed upon
+solution are listed in the document containing the problem statement and
+agreed upon solution.
 
 The general work flow is that a problem is identified and the problem
-statement is formulated. The working copy of the Problem Statement is tracked
-in documents/problems. Once a solution statement has been formulated the
-document migrates from documents/problems to documents/proposals. The proposal
-should be vetted on distribution mailing lists, and as it develops, by a 
-matching statement in the version control system, to the precise language 
-of the Problem Statement. Major threads in the discussion should be
-referenced by pointers included by reference link to the archive 
-in the proposal. After a consensus
-is reached and implementation can commence, and the proposal becomes a de facto
-standard and migrates to documents/specifications. Unless specifically stated
-no document should become an accepted specification without an accompanying
-test that allows distributions to self monitor their compliance to the
-agreed upon de facto standard. An accepted specification contains a list
-of distributions that have undertaken to meet the specification and 
-have integrated the appropriate test in their distribution test suite.
+statement is formulated. The problem identification generally happens via
+the issue tracker in GitHub. Once a problem statement is formulated a pull
+request for the document located in documents/wip should be issued. A second
+step is the creation of a solution proposal which may then be solicited
+to distributions for discussion. Once consensus is reached the solution is
+committed to documents/specifications without additional changes. Changes
+to accepted solutions should only consist of trivial fixes for spelling and
+grammar as well as additions of new distributions pledging to support
+a given specification.
+
+The solicitation of a Problem Statement or a Solution Proposal should
+occur on a distribution public mailing list and a link to the thread
+should be included in the document.
+
+Unless specifically stated no document should become an accepted
+specification without an accompanying test that allows distributions to self
+monitor their compliance to the agreed upon de facto standard.
 
 Contribution guidelines are provided in the Contributing.txt file in the
 top level of the repository.

specification.tmpl

@@ -1,5 +1,21 @@
 LSB Specification
 
+State:
+-----
+Acceptable values are:
+"Problem Statement"  -> Problem Statement has been formulated
+"Problem Solicitation" -> The problem statement is being solicited to
+                          distributions to reach agreement on the problem
+                          itself, i.e. is this something that needs to be
+                          solved
+"Solution Proposal"  -> Solution to the problem has been proposed
+"Solicitation" -> The proposed solution is being solicited to distributions
+                  in an attempt to find a consensus solution.
+"Accepted" -> A consensus solution has been found and the solution
+              is ready for implementation.
+
+The state should be indicated in line with the State: header
+
 Problem Statement:
 ------------------