On Wed, Dec 11, 2013 at 12:00:25PM +0100, Antonio Larrosa wrote:
Hi all,
We got lots of feedback from you all, also on the process. Many did not appreciate the long and complicated emails. We discussed this in the team and Tomáš Chvátal told us how Gentoo shares a nicely documented change process with Python and Debian already. Essentially, they use a standardized document which ensures that whenever something has to be discussed, all information is there right at the start. This shortens discussions, avoids bikeshedding (see [1]) and afterwards you have a nice stash of proper proposals in archive.
The proposal is essentially based off of the Python document, simplified and adapted to openSUSE. It does not change how decisions are made or by who, just speeds up the process, keeps the discussions clean and documents their results thus avoiding future flames. We think it would be great for openSUSE to adapt them.
Attached to this mail there's a draft with a recursive OSEP in the proper, proposed form, let us know what you think ;-)
Note that the draft we made only proposes to use this for big changes to our process, not technical things like replacing sysvinit with systemd.
FYI, Agustin has written on our team blog about the proposals, giving an overview of what's out: http://lizards.opensuse.org/?p=10230
-- The openSUSE Team
[1] http://blog.jospoortvliet.com/2011/09/bikeshedding-and-cls.html
Hi openSUSE team, I appreciate such move from unstructured mess of various email threads and discussions to something much easier to deal with and to follow!
_____________________________________________________________________ OSEP: 0001 Title: Process proposal: openSUSE Enhancement Proposal Version: 0.1 Last-Modified: 10 Dec 2013 Author: Jos Poortvliet
, Antonio Larrosa Status: Draft Type: Process Created: 02 Dec 2013 Post-History: _____________________________________________________________________ Process proposal: openSUSE Enhancement Proposal -----------------------------------------------
OSEP (_openSUSE Enhancement Proposal_) is a document providing information to the openSUSE community or describing a process in Factory or its environment. The OSEP should provide a concise specification and rationale of the process it's explaining.
OSEPs are intended to be the primary mechanisms for proposing major new procedures and for documenting the design decisions that have gone into Factory. The OSEP author is responsible for building consensus within the community and documenting dissenting opinions.
Because the OSEPs are maintained as text files in a versioned repository, their revision history is the historical record of each proposal footnoteref:[note_repo, https://www.github.com/TBD].
So do you want to maintain OSEPs in some github repo? Would not that be overkill compared to wiki, which provides the same set of features you want?
OSEP Types ----------
There are two kinds of OSEP:
- An _Informational OSEP_ describes an issue, or provides general guidelines or information to the openSUSE developers, but does not propose a new feature. Informational OSEPs do not necessarily represent a community consensus or recommendation, so users and implementers are free to ignore Informational OSEPs or follow their advice.
What is the reason to spent a time on creating and discussing a proposal, which will ends in informational state? Do you have any example, where the process is worth effort, but the result is not that important?
- A _Process OSEP_ describes a process surrounding Factory, or proposes a change to a process. They may propose an implementation, but not to packages; they often require community consensus; unlike Informational OSEPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, changes to the decision-making process, and changes to the tools or environment used in Factory development.
Submitting an OSEP ------------------
The OSEP process begins with a new idea for openSUSE. It is highly recommended that a single OSEP contain a single key proposal or new idea. Small enhancements or patches don't need an OSEP.
It's recommended that the author of an OSEP brings his/her idea to key people from the community to see the acceptance the idea would have before sending it for review. The received feedback should be introduced in the first draft document, so that it's as complete as possible and long open-ended discussions on public mailing lists are avoided.
Once a draft is written in the style described below, it should be presented to the _opensuse-factory_ mailing list.
it MUST be presented on opensuse-$FOO mailinglist - having mandatory OSEP not beeing discussed in a public is a no-go. Please make sure you use the keywords as defined in RFC2119 http://www.ietf.org/rfc/rfc2119.txt
OSEPs should be submitted in asciidoc format footnoteref:[asciidoc_userguide, http://www.methods.co.nz/asciidoc/userguide.html] with UTF-8 codification.
OSEPs may include auxiliary files such as diagrams. Such files must be named +osep-XXXX-Y.ext+, where _XXXX_ is the OSEP number, _Y_ is a serial number (starting at 1), and _ext_ is replaced by the actual file extension (e.g. +png+).
Again, what is wrong with a wiki? Pages can be even blocked, so only author can change them ... there can be even a template and fancy boxes for a state. And it is not that hard to get the text form to send it to ML. Regards Michal Vyskocil
[snip]