%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -*- Mode: Latex -*- %%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% selinux.tex --- 
%% Author           : Manoj Srivastava ( srivasta@glaurung.internal.golden-gryphon.com ) 
%% Created On       : Thu Jun  7 12:03:41 2007
%% Created On Node  : glaurung.internal.golden-gryphon.com
%% Last Modified By : Manoj Srivastava
%% Last Modified On : Fri Jun 15 09:20:21 2007
%% Last Machine Used: glaurung.internal.golden-gryphon.com
%% Update Count     : 21
%% Status           : Unknown, Use with caution!
%% HISTORY          : 
%% Description      : 
%% 
%% arch-tag: ed0cbe62-9a36-4f0f-bc1b-995d471c0d72
%% 
%% Copyright © 2007 Manoj Srivastava <manoj.srivastava@stdc.com>
%% All rights reserved.
%% 
%% This paper is free software, you can redistribute it and/or modify
%% it under the terms of either:
%% 
%%  a) the GNU General Public License as published by the Free Software
%%      Foundation; Version 2, or
%% 
%%  b) the "Artistic License"
%% 
%% On Debian GNU/Linux systems, the complete text of the GNU General
%% Public License can be found in `/usr/share/common-licenses/GPL' and
%% the Artistic Licence in `/usr/share/common-licenses/Artistic'.
%% 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\documentclass[ignorenonframetext,utf8x]{beamer}
%\documentclass{article}
%\usepackage[envcountsect]{beamerarticle}

\usepackage{times}
\usepackage{graphicx}

\usepackage[english]{varioref}
\usepackage{fancybox}
\usepackage{url}
\usepackage{natbib}
\usepackage{multimedia}

\mode<presentation>
{
  \usetheme{PaloAlto} 
  % or ...
  \usecolortheme{albatross}
  \setbeamercovered{transparent}
  % or whatever (possibly just delete it)
}

\newcommand{\mytitle}{The Policy and RC bug goulash}

\mode<article>
{
  \setlength{\topmargin}{0pt}
  \setlength{\oddsidemargin}{0pt}
  \setlength{\evensidemargin}{0pt}
  \setlength{\headheight}{20pt}
  \setlength{\headsep}{20pt}
  \setlength{\footskip}{35pt}
  \setlength{\textheight}{9.0in}
  \setlength{\textwidth}{6.5in}

 \usepackage{fancyhdr}
 \pagestyle{fancy}
 \addtolength{\headheight}{\baselineskip}
 \renewcommand{\sectionmark}[1]{\markboth{#1}{}}
 \renewcommand{\subsectionmark}[1]{\markright{#1}}
 \rhead{\leftmark\\\nouppercase{\rightmark}}
  \fancyhead{} % clear all header fields
  \fancyfoot{} % clear all footer fields
  \fancyhead[LE,RO]{\bfseries\thepage}
  \fancyhead[LO]{\bfseries\rightmark}
  \fancyhead[RE]{\bfseries\leftmark}
  \fancyfoot[CE,CO]{\bfseries \mytitle}
  \renewcommand{\headrulewidth}{0.4pt}
  \renewcommand{\footrulewidth}{0.4pt}

%%\lhead{\fancyplain{}{\bfseries{\rightmark{}}}}
}

\institute[S/TDC]%
{
  System/Technology Development corp
}

\mode<article>
{
  \title{\mytitle{}\\
       \Large
{echnical policy, release policy, developers reference, lintian/linda: How do these fit?}}
\author{Manoj Srivastava\\
  Copyright \copyright{} 2007.  All rights reserved.}
\date{\today}
}

\mode<presentation>
{
  \title{\mytitle{}}
  \author{Manoj Srivastava}
  % - Give the names in the same order as the appear in the paper.
  % - Use the \inst{?} command only if the authors have different
  % affiliation.
  \institute[Debian]%
  {
    The Debian project
  }
  % - Use the \inst command only if there are several affiliations.
  % - Keep it simple, no one is interested in your street address.
  \date{Debconf7}
  % - Either use conference name or its abbreviation.
  % - Not really informative to the audience, more for people (including
  % yourself) who are reading the slides online

  % If you wish to uncover everything in a step-wise fashion, uncomment
  % the following command: 
  \beamerdefaultoverlayspecification{<+->}
}

% This is only inserted into the PDF information catalog. Can be left
% out. 
% \subject{\mytitle{}}


% Delete this, if you do not want the table of contents to pop up at
% the beginning of each subsection:
\AtBeginSubsection[]
{
  \begin{frame}<beamer>
    \frametitle{Outline}
    \tableofcontents[currentsection,currentsubsection,hideothersubsections]
  \end{frame}
}


\begin{document}

\mode<article>
{
  \maketitle{}
  \thanks{\hfill{}
    \begin{minipage}[htb]{0.8\linewidth}
      This paper is free software, you can redistribute it and/or
      modify it under the terms of either the GNU General Public License
      as published by the Free Software Foundation; Version 2, or the
      ``Artistic License''.  On Debian GNU/Linux systems, the complete
      text of the GNU General Public License can be found in
      `\texttt{/usr/share/common-licenses/GPL}' and the Artistic Licence
      in `\texttt{/usr/share/common-licenses/Artistic}'. \newline{}
    \end{minipage}\hfill{}
  }
  \begin{abstract}
    There are a number of documents and tools related to packaging
    software in Debian, which lie on different points along the
    spectrum of mandatory standards and suggested style tips. This
    talk talks about the differences in the goals of the various
    documents and tools, and will go into the upcoming update of the
    technical policy update process, and how people can contribute. 

    There has been some confusion about the distinction and
    differences between technical policy, release policies,
    lintian/linda, and the developers reference. There was also some
    question about what exactly is the relationship between policy
    violations and release critical bugs, and why there needs to be
    two related but differing sets of rules. 

    Additionally, there around the time that the policy team was
    re-delegated, a discussion started about revamping the policy
    update process. This talk will bring in the current thinking on
    the issue, and the informal meeting style should allow for a
    discussion of the proposed process. 
  \end{abstract}
}

\nocite{*}

\mode<presentation>{
  \begin{frame}
    \titlepage
  \end{frame}


  \begin{frame}
    \frametitle{Outline}
    \tableofcontents[pausesections]
    % You might wish to add the option [pausesections]
  \end{frame}
}
\section{Introduction}
\label{sec:intro}

\mode<article>{
  What is the role of policy and style documents in Debian? Why should
  we spend time and effort on this at all? Well, there is no single
  answer to that question. There are a number of differing
  requirements that drive the documents, with varying utility curves
  and added value that they provide. I'll take a stab at trying to
  identify some of these variations:

  \begin{itemize}
  \item Setting up integration requirements. There are a number of
    instances in which a number of technically viable but incompatible
    solutions, and one of them needs to be selected in order for the
    packages to be compatible. This should be the most common case.
  \item There are interface details about the packaging system that
    package maintainers may rely upon for their packages, and the
    packaging system must support.
  \item There are certain packaging rules that need to be followed in
    order for smooth upgrades, or localization, or multiple
    architecture support -- in other words, driving features that
    the Debian project as a whole has decided to support. 
  \item There are standards of quality control that must be met which
    are designed to reduce flaws in packages (lower the bug count).
  \item There are compilations of tips and best practices that might
    be helpful to package maintainers
  \item HOWTO's, walk throughs, tutorials, etc
  \end{itemize}

This talk deals with two things: reorganizing policy document, and
reorganizing how policy documents are changed. And the sticking point
in a number of cases is policy process got stuck was when there was no
clearcut correct solution, and it was unclear whether discussion was
over, or which of competing solutions to pick. The process I outline
below will ensure a timely handling of policy proposals, and make
better use of a rejuvenated TC to decide the tricky technical proposals.

}


\mode<presentation>{
  \begin{frame} \frametitle{What is the role of policy/style docs?}
    There are a number of differing drivers:
    \begin{itemize}
    \item<1-> System integration requirements
    \item<2-> Packaging System interface (maintainer scripts, etc.)
    \item<3-> Upgrade requirements
    \item<4-> QA standards designed to reduce bugs
    \item<5-> Best practices and compendium of tips 
    \item<6-> HOWTO's, tutorials, walk throughs
    \end{itemize}
  \end{frame}
%         My view of policy has been a minimalistic document, something
%  that has little bloat, and can be taken in without too much effort
%  (little bloat). I have said it better before:

% ,----[ policy-process ]
% |   1.1. Guidelines for policy change proposals
% | -------------------------------------------
% | 
% | Policy does not document all existing practice.  It only incorporates
% | a minimal ruleset that is required for systems integration (usually
% | selecting one branch from several equally viable technical options).
% | It is not a best practices document.
% | ...
% | 
% | Nor does policy _always_ document only existing practices.  What that
% | oft misquoted statement refers to was a part of a larger thesis that
% | is meant to suggest that policy is not the place for testing out
% | design; if a complicated technical proposal is to be made into policy,
% | it should be independently implemented, have all the kinks worked out,
% | and then have that working model be implemented as policy.  Having to
% | change policy back and forth while a design is being worked out needs
% | be avoided.
% `----

  \begin{frame} \frametitle{What are the types of content?}
    \begin{itemize}
    \item<1-> Items absolutely required for integration (violating
      that degrades functionality)
    \item<2-> Things which drive features the project has decided are
      important for the OS
    \item<3-> Things that are, in all but uncommon cases, the right
      things to do
    \item<4-> Things that might become required in the future (future
      features, etc)
    \item<5-> Things which are nice to have, but not critical
    \item<6-> Aesthetically pleasing things, and subjective best
      practices
    \end{itemize}
  \end{frame}

  \begin{frame} \frametitle{Categorization}
    \begin{itemize}
    \item<1-> Things which maintainers \textbf{must} do, or else cause
      a decrease in features or quality of the distribution
    \item<2-> Things which the maintainers \textbf{should} do, or
      demonstrate the case is exceptional
    \item<3-> Things that are \textbf{recommendations}
    \end{itemize}
  \end{frame}
}
\section{Reorganizing Policy}
\label{sec:rewrite}

\mode<presentation>{

  \begin{frame} \frametitle{Policy Lacunae}
    \begin{itemize}
    \item<1-> Current policy is bloated, contains material not mean
      for policy
    \item<2-> The must/should/may labels are not consistent, or
      correct (the separate RC bug listings are a symptom)
    \item<3-> Far too many policy documents, need consolidation
    \item<4-> Too hard to judge level of compliance for package
      maintainers.
    \item<5-> Not all rules have rationale, and there are no suggested
      checks for policy conformance checkers.
    \end{itemize}
  \end{frame}

  \begin{frame} \frametitle{Case for rewriting policy}
    \begin{itemize}
    \item<1-> Policy started as \texttt{dpkg} documentation, and
      must/should/have clauses might be incorrect.  The policy should
      be closer to release goals; a release team RC criteria list
      should not be ever required.
    \item<2-> We can divide policy based on how critical it is to
      follow the rules; making it easier to judge conformance
    \item<3-> Use docbook for the new policy manuals. A multi-part
      book allows the creation of a comprehensive
      book from different documents with differing inclusion and
      editing criteria
    \item<3-> Docbook is popular, well maintained, allows indices and
      cross references, and has many rendering formats
    \item<4-> Copyright of current document unclear, at best
    \end{itemize}
  \end{frame}


  \begin{frame} \frametitle{Case for rewriting policy, cont'd}
    \begin{itemize}
    \item<1-> The new document can be built up with a clear convention
      for normative rule, informative rationale, and optional package
      checking pseudo code
    \item<2-> The policy rules can come under a long overdue review,
      and consistent editorial practice would benefit readability
    \item<3-> Cruft removal. Indices. Cross references.
    \item<4-> Some material should move to the developers reference,
      or similar best practices manuals.
    \item<5-> A one stop shop for all packaging materials, with
      decreasing criticality and perhaps increasing size, would make
      packaging easier.
    \end{itemize}
    \only<6->{Questions?}
  \end{frame}
}
\section{The policy change process}
\label{sec:change}

\mode<presentation>{
  \begin{frame} \frametitle{Policy Change Goals}
    \begin{itemize}
    \item<1-> The change should be technically correct, and consistent
      with the  rest of the policy document. This means no legislating
      the value of $\Pi$. This also means that the proposed solution
      be known to work; iterative design processes do not belong in
      policy. 
    \item<2-> The change should not be too disruptive; if very many
      packages become instantly buggy, then instead there should be a
      transition plan.  Exceptions should be rare (only if the current
      state is really untenable), and probably blessed by the TC.
    \item<3-> The change has to be reviewed in depth, in the open,
      where any one may contribute; a publicly accessible, archived,
      open mailing list.
    \item<4-> Proposal should be addressed in a timely fashion.
    \end{itemize}
  \end{frame}
  \begin{frame} \frametitle{Policy Change Goals, cont'd}
    \begin{itemize}
    \item<1-> Any domain experts should be consulted, since not every
      policy mailing list subscriber is an expert on everything,
      including policy maintainers.
    \item<2-> The goal is rough consensus on the change, which should
      not be hard if the matter is technical. Technical issues where
      there is no agreement should be referred to the TC;
      non-technical issues should be referred to the whole developer
      body, and perhaps general resolutions lie down that path. 
    \item<3-> Package maintainers whose packages may be impacted
      should have access to policy change proposals, even if they do
      not subscribe to policy mailing lists (policy gazette?).
    \end{itemize}
  \end{frame}
  \begin{frame} \frametitle{Policy Change as a state machine}
    \begin{itemize}
    \item<1-> \textbf{State A}: Detect need, like gaps/flaws in
      current policy, or a new rule should be added. Any user or
      developer may start this step. There is a decision point here,
      not all issues are in scope of policy.
    \item<2-> \textbf{State B}: Discuss remedy. Alternate
      proposals. Discussion guided by delegates. There should be a
      clear time limit to this stage.
    \item<3-> \textbf{State C}: [Optional] Solicit domain expert input
    \item<4-> \textbf{State D}: Close to a working solution. Create
      policy language, rationale, test, and publish.
    \item<5-> \textbf{State E}: The proposal is signed off on by N
      developers, N=3? (stages D and E may be reversed) Final
      discussions start; input from affected developers.
    \end{itemize}
  \end{frame}
  \begin{frame} \frametitle{Policy Change Result States}
    \begin{itemize}
    \item<1-> \textbf{State F}: Change accepted, will be in next upload.
    \item<2-> \textbf{State G}: Not a policy matter
    \item<2-> \textbf{State H}: Timed out, no policy created.
    \item<2-> \textbf{State I}: Referred to TC
    \item<2-> \textbf{State J}: Referred to developer body 
    \item<2-> \textbf{State J}: Rejected by delegates (sent by default
      to TC)
    \end{itemize}
  \end{frame}
  \begin{frame} \frametitle{Tracking progress}
    \begin{itemize}
    \item<1-> Continue to use the BTS
    \item<2-> Use usertags to monitor progress
    \item<3-> Use automated mails to remind about proposal deadlines
      and milestones (using user tags).
    \end{itemize}
  \end{frame}
  \begin{frame} \frametitle{Proposed process}
    \begin{itemize}
    \item<1-> 1. Trivial policy updates that don't change the substance
      of policy (markup changes, fixing typos) will be made by the
      policy maintainers as they see fit.
    \item<2-> 2. Flaws/Defects  in policy should have a normal or
      important bug  filed against policy in the BTS.  The usertag is
      the one reserved  for ``\textbf{State A}''.
    \item<3-> 3. Gaps in policy should be filed with a wishlist
      priority. Usertag the one reserved for ``\textbf{State A}''.
    \item<4-> 4. If a solution is also proposed, the usertag is the
      one related to ``\textbf{State B}'', skip to 6.
    \item<5-> 5. Discussion occurs, and a tentative solution is
      proposed. There is time limit for this step. The usertag is the
      one related to ``\textbf{State B}''.
    \end{itemize}
  \end{frame}
  \begin{frame} \frametitle{Proposed process, cont'd}
    \begin{itemize}
    \item<1-> 6. Input is solicited from domain experts, as needed.
      Time is allowed for such experts to provide input.
    \item<2-> 7. Once three developers or one of the policy
      maintainers (other than the proposer) have indicated they
      support the proposed change, usertag corresponding to stage E is
      added. 
    \item<3-> 8. Formal policy language is specified for the
      bug. usertag corresponding to ``\textbf{Stage D}'' is added.  At
      this point, this bug gets sent to the policy-announce mailing
      list. Final reviews and discussions start, with a time limit.
    \item<4-> 9.  Policy should be designed to meet the concerns of
      all developers, and all suggestions should be taken into account
      as far as possible. 
    \end{itemize}
  \end{frame}
  \begin{frame} \frametitle{Proposed process, cont'd}
    \begin{itemize}
    \item<1-> 10. At the end of the discussion period for the
      proposal,a resolution is required (the discussion period may be
      extended at the discretion of the delegates). 
    \item<2-> 11.  If the policy maintainers are satisfied
      with the proposed change, the patch will be committed to the
      policy revision control system. usertag: ``\textbf{State F}''.
    \item<3-> 12. If policy maintainers think that the proposed change
      does not meet the concerns of all maintainers, or no formal
      language or solution can be agreed upon, they may forward the
      issue to the TC or the developer body; usertags for States H, I,
      or J may be added. 
    \item<4-> 13. If the policy maintainers are not satisfied with the
      proposed change, they may make suggestions, or tag the bug
      ``wontfix''. usertag: ``\textbf{State K}''.  Such cases are
      automatically forwarded to the TC for review.
    \end{itemize}
  \end{frame}

}


% ,----[ Debian Policy ]
% | 1.4. Related documents
% | ----------------------
% |  In addition to those, which carry the weight of policy, there is the
% |  Debian Developer's Reference.  This document describes procedures and
% |  resources for Debian developers, but it is _not_ normative; rather, it
% |  includes things that don't belong in the Policy, such as best
% |  practices for developers.
% `----

%         Do you think we should review these distinctions?  I agree
%  that a single package to look at might be a good idea; but the
%  differing goals often mean different teams and different editing
%  criteria; so there are practical obstacles.

% On 26 Jun 2006, Ian Jackson wrote:

% > Frank K<FC>ster writes ("Re: Bug#375502: debian-policy must clarify how
% > sub-policies should be managed"):
% >> For a document called "Debian-Foo-Policy" to be part of The Debian
% >> Policy it must be included in 1.4.  If it is not included there, it
% >> is not mandatory policy.  How is that unclear?
% >
% > The list in 1.4 isn't necessarily complete.

%         I am of the opinion that it is.  At least, it is meant to be
%  complete, anything that is official technical policy for
%  Debian should be available when one installs the debian-policy
%  package. 

% >> Otherwise, nobody hinders me to write a document and call it
% >> "Debian TeX Policy" (or "Debian Shakespeare Policy" or "Debian
% >> Lesbian Policy" ;-)) and install it with one of my packages.  It's
% >> clear that this doesn't imply any normative value.
% >
% > If you write the Debian TeX policy then it's just as normative as
% > the debian-policy manual.  If it's full of nonsense and you refuse
% > to remove it then someone will complain to the Technical Committee
% > and the TC will instruct you to remove it from the package.

%         This is not how I interpret the document.  I would call the
%  TeX policy document a draft policy, which TeX develoeprs may chose to
%  follow. However, the draft document can change rapidly, without the
%  oversight and the process that this mailing list imposes. When the
%  sub policy is considered mature, it ought to be submitted for
%  inclusion. 

% > For starters, the OCAML policy should be put in some package.  But
% > you should also file a bug asking for 1.4 to be changed to include
% > it in the list.

%         Following the policy upgrade process, please.
% On 26 Jun 2006, Frank K<FC>ster spake thusly:

% > Ian Jackson <ian@davenant.greenend.org.uk> wrote:
% >
% >> Frank K<FC>ster writes ("Re: Bug#375502: debian-policy must clarify
% >> how sub-policies should be managed"):
% >>> I tend to disagree.  A sub-policy should only be part of the
% >>> debian-policy package, and installed in
% >>> /usr/share/doc/debian-policy, if it is accepted and has been
% >>> established through the official policy process.
% >>
% >> There is no `official policy process'.  Manoj has (very wisely IMO)
% >> abolished the previous bureaucracy and returned to editing the
% >> manual according to his own judgement - taking into account of
% >> course the advice and information of others including probably the
% >> rough consensus of this mailing list.

%         Well, I would have changed the emphasis a bit, but this is
%  somewhat  right.  I just use the policy process as outlined to help
%  me decide on what the rough consensus is, and to help me assign
%  priorities to the tasks.

% > Is this really true?  Then why hasn't the policy-process document
% > been deleted from the binary package?  And why did we see people
% > sending "Seconded" messages to this list and counting seconds,
% > without anybody calling "Hey guys, this is useless"?

%         Umm, this is not quite what I had in mind.  There is still a
%  policy process; it allows people other than the policy editors to
%  broach and discuss enhancements to the policy, it allows domain
%  experts to add their voices, and it makes the policy delegate's jobs
%  easier.
%         What has happened is that with formal delegation I think I can
%  act without the full process where the issue appears to have an
%  obvious and clear resolution.  While the policy process is still the
%  preferred means of getting policy to be changed, I also am cognizant
%  f the fact of life that people often do not follow the process.
%  Since the policy editors are now delegates, I can afford to not be as
%  anal retentive about bureaucracy as I had been, and can act when the
%  proposal is a clear flaw in policy.  I would much rather not have to
%  do this too often, since I, being human, make mistakes (note the
%  cgi-lib fiasco from earlier this year).

%         So please, do follow the process outlined, and feel free to
%  poke me on issues. Also, Marga is working on a set of
%  usertags/usercategories that would help us all categorize bugs on
%  policy, and that would perhaps streamline the process, and help
%  direct our energies where they are most needed.

% >> So there is no difference in the authoritativeness of the policy in
% >> debian-policy versus that in any other package.  These policies are
% >> all authoritative 

%         I tend to disagree.  

% >> > The technical committee charter and the policy process both adopt
% >> > the principle that the people making the change [..] only act in
% >> > an editorial capacity -- reviewing changes and committing them
% >> > appropriately, but not do actual design work in their formal
% >> > hats.
% >> But they also take the lead in discussions, and can and do decide
% >> if there are opposing opinions as to which opinion carries the
% >> day. Part of taking lead in the discussion is having the ability to
% >> say "Stop, we have heard all arguments on this already, based on
% >> the current positions of people on the list, this option is what we
% >> shall decide to do.".

%         It is also nice to be able to give weight to domain expert
%  opinions. If we are discussing, say, policy about some aspect related
%  to the debian installer, and joeyh or frans pop provide input, and
%  even if fifty random people who never worked on the installer jump up
%  saying that that's not how the installer works, or, if it does, that
%  is not how it is supposed to work and, anyway , frans only said that
%  to hurt them -- it is nice to able to do more than just count up the
%  numbers of opinions voiced.

%         Why is this relevant? Well, the before the delegation, I had
%  no authority to abridge discussion even after we started going around
%  in circles.  There was no way to give some opinions more weight than
%  others. That is why for years anything remotely controversial could
%  not be included in policy -- there was no way to do anything without
%  a near consensus.

%         Understand this: the old policy process proposal was written
%  in this atmosphere. If you read back in the archives, you'll find
%  that I did mention back in those days (and often later as well) that
%  we had to walk softly, since we had no real constitutional authority
%  to be changing at all.

%         Since there was no authority for a moderator, the process was
%  overly bureaucratic.

%         After the delegation, the process followed changed -- people
%  have gotten changes into policy without  doing the BTS dance, usually
%  for non-controversial and obvious changes that were no brainers.

%         Even no-trivial changes, if there is no controversy,  have
%  gone in, since there is no reason to remain so bureaucratic. I
%  suppose I should have modified the document, but well, things were
%  working all right, and it is not on the top of the heap of the TODO
%  things. 

%         The old process, meant for pre delegation days, really should
%  be revised. It is not really followed in practice a whole lot, to be
%  honest.

%         This is not to say there is no review of content, for any
%  proposal.  The actual review process happens on the mailing list.
%  Often, not all discussion makes it to the BTS, even for issues being
%  tracked by the BTS (which is why I have a full archive for policy in
%  Gnus).

%         What do we use the BTS for? Well, we use the BTS as a book
%  mark.  Once an issue has gone beyond initial discussion,  I ask
%  people to file a bug at wishlist so it does not get off my radar.

%         I often can't follow all the discussion in real time, and so
%  lose track of what status the proposal is at -- I'll get to
%  all of them when I catch up, but if someone figures out we have
%  consensus, and so marks up the bug on the BTS, it helps me prioritize
%  what I work on.

%         The getting three people to agree on something is just to cut
%  down on zany proposals that would otherwise accrue -- and  again,
%  that is part of that document that we need to rethink in light of
%  delegation. 

%         The stress should be on review, rough consensus, input from
%  domain experts,  sane, _contained_ discussion, and technical
%  correctness being the goal, not popularity of opinion. The old
%  process did not really ensure any of this (apart from a nebulous
%  consensus as a goal.)

%         This is not actually the case, as I have explained.  The
%  review process is the critical issue here -- and the review is
%  carried out on the mailing list.  This is not unique in Debian (no
%  BTS for legal that I am aware of).

%         I never said there will be no review. Indeed, since I am
%  conducting this process, the review has to be even more strict -- I
%  dare not abridge discussion nor decide what is expert testimony as
%  readily as I would in a discussion I was not involved in. 

%         The old process of proposers and seconds is also something is
%  deem necessary --  if I do not have most developers on -policy
%  behind it, including the release team leads, the policy changes are
%  dead in the water. Formally asking two people to second this process
%  when we clearly need a heck of a lot more seems ... red tape.

%         The old document also sates that the whole process could be
%  stopped dead in its tracks by a single formal objection. And then we
%  deferred to the TC or took a vote.  I think that is a flaw -- if
%  there are serious objections from a significant minority of active
%  members of the mailing list, sure, we should punt to the TC or a GR,
%  but not if there is one lone objection.

%         In the old days, I had no authority to overrule even a single
%  objection. Now I think that Debian has changed -- no matter what the
%  issue, you can probably find a handful of very vocal people to block
%  it. I think we need to re-examine when we should take the discussion
%  out of the mailing list and let more developers or the TC in, but I
%  do know the number ought to be greater than one.

%         Indeed, if I can't get at least a dozen people to sign off on
%  the final version, this process is dead.

% > If that's not your view -- and I would have thought it wasn't -- I'd
% > be happy to renew the delegation, but so far you haven't clearly
% > said that.

%         You never so clearly asked :)

% > (Personally, I'd rather have an additional three-seven people to
% > delegate too; but I'm afraid I don't have any brilliant ideas on who
% > that could be)

%         Good luck.  I have been trying for 8 years to get help on
%  policy, but counting the changelog updates, I have had an abysmal
%  track record.


% > Agreed absolutely.

% > The only point I'm emphasising is that you don't just have to hear
% > the arguments, you have to ensure they're made somewhere that others
% > can hear them too.

%         I agree. And the place where people can here the arguments is
%  the debian-policy mailing list; even under the old process, porposals
%  were refined on the list, and areguments were put forth for and
%  against alternate strategies that helped shape the final proposal;
%  and the final proposal was what was put to the BTS, and seconded, and
%  only the final polishing discussion ever made it to the BTS.

%         This is similar in nature to general resolutions: the
%  arguments made on the debian-vote list are not what makes it to the
%  vote.debian.org mailing list.

% > So does something like the following sound plausible?

% >   1. Trivial policy updates that don't change the substance of
% >      policy (markup changes, fixing typos) will be made by the
% >      policy maintainers as they see fit.

% >   2. Other changes will have a patch submitted against a bug
% >      assigned to the debian-policy package in the BTS, and forwarded
% >      on to any developers specifically affected by the proposed
% >      changes.

% >   3. Once three developers or one of the policy maintainers (other
% >      than the proposer) have indicated they support the proposed
% >      change, the bug can be tagged "confirmed", and will then be
% >      reviewed by the policy maintainers as a group.

% >   4. If the policy maintainers are satisfied with the proposed
% >      change, the patch will be committed to the policy revision
% >      control system and the bug will be tagged "pending".

% >   5. If at any point the policy maintainers are not satisfied with
% >      the proposed change or the reasoning behind it, they may make
% >      suggestions tag the bug "wontfix", and/or close the bug.

% >   6. Policy should be designed to meet the concerns of all
% >      developers, and all suggestions should be taken into account as
% >      far as possible.

% > That has a single process that applies to everybody, seems
% > reasonably quick for changes the maintainers propose, works even if
% > there's only one active policy maintainer, and requires at least one
% > person other than the proposer to review every change.

% > I assume you can already think up a bunch of improvements to the
% > above skeleton, but does the general shape match what you're
% > thinking?

%         That is a good starting point. But if we are going to revamp
%  the policy modification process, let us examine the goals, and the
%  logical states of the state machine of a policy change use case.

%         Goals:
%  1) The change should be technically correct, and consistent with the
%     rest of the policy document. This means no legislating the value
%     of Pi
%  2) The change should not be too disruptive; if very many packages
%     become instantly buggy, then instead there should be a transition
%     plan.  There could be very rare exceptions to this rule, if the
%     current state is really untenable. In which case, though, the TC
%     should probably be involved.
%  3) The change has to be reviewed in depth. The discussion should be
%     held in the open, where any one may contribute; a publicly
%     accessible, open mailing list which is archived should be fine.
%  4) Any domain experts should be consulted, since not every policy
%     mailing list subscriber is an expert on everything, including
%     policy maintainers.
%  5) The goal is rough consensus on the change, which should not be
%     hard if the matter is technical. Technical issues where there is
%     no agreement should be referred to the TC; non-technical issues
%     should be referred to the whole developer body, and perhaps
%     general resolutions lie down that path.
%  6) Package maintainers whose packages may be impacted should have
%     access to policy change proposals, even if they do not subscribe
%     to policy.

%         This last bit is where I am slightly concerned -- we have
%  never done a good job on early notification. However, with 15,000
%  packages and climbing, putting the task of determining which packages
%  are affected can be very burdensome on the active policy maintainers
%  (heh).  I would suggest instead a Weekly Policy News, or the Policy
%  Monthly Gazette, or something, that people may subscribe to for a low
%  volume announcement list. Indeed, it can be an announce only list,
%  and a synopsis of the proposal and a rationale can be posted to it
%  when we reach the stage where the proposal is nearing the final form.

%         Given these goals, what are the steps or stages to reach
%  there? Here is my take at the states of a state machine:

%  State A: There is a gap in current policy. For example, if  there are
%           potentially several technically viable options that can be
%           taken, and it would help integration if all packages
%           affected can rely on one solution, it would help
%           integration.
%   Any user or developer should be able to point to such a deficiency,
%   and this can be an injection point of a policy change into the
%   system. There is a decision point here: some issues raised might not
%   be in the purvue of a policy change (I do not like the name
%   iceweasel, policy should prevent ice and a rodent in the name of any
%   package).  This state is optional, some proposals can go right to
%   stage B

%   State B: Initial suggestions for a policy to address some such
%            need. This may not have formal policy language yet, or a
%            diff against current policy.

%  This is when discussion happens, alternate proposals are floated, and
%  the nitty-gritty details of policy creation are done. Policy
%  delegates, if any, should guide, but not control, this discussion;
%  they can help nudge the process along if the discussion has reached
%  an impasse, suggesting one alternative or the other.  The guidance
%  could stop a circular discussion in which no new arguments are
%  forthcoming and decide in favour of the majority opinion, for
%  instance, to prevent a vocal minority from derailing the
%  process. Much care has to be exercised here, and we should probably
%  come up with a means for appealing any thing -- to another policy
%  delegate, perhaps?

%  If there is an arcane technical area involved, and there are domain
%  experts for that area, we may optionally go to:

%  Stage C: Solicit domain expert input.  In most cases, it is easy to
%           determine who the domain experts are; usually the maintainer
%           of related packages either are domain experts or can point
%           to domain experts.  This state is optional, and has two exit
%           points: either we get the domain expert testimony, and
%           perhaps a dialogue ensues, or we time out (I mean, domain
%           experts need not pay attention to us, etc)

%  At this point, there should either be the case where we have a fair
%  idea of what change is required, or have come to the conclusion we
%  can't agree. There should be support from three developers at this
%  point, before we proceed to the next phase (or a developer and a
%  delegate -- dunno if we should really special case the delegate here)

%  State D: Formal change language is created for the policy change, any
%           transition plans are sketched in, a rationale is attached as
%           a footnote, if appropriate, for future reference. At this
%           point, the policy change goes to the Policy Gazette, so
%           other people affected may join the discussion, if they
%           please.

%  State E: The proposal is sponsored by three developers.

%  States D and E may happen in any order, but both are required before
%  we move to the next state.

%  Final discussions happen here. There should be ample time for people
%  who are affected by this change to have read the Gazette and come in
%  to voice their inputs; final refinements to the language happen now.
%  This is again a decision point; either we have a rough consensus, or
%  we need to send the initial problem, and the fact we can't agree, off
%  to the TC or the developer body at large.

%  State F: the change is accepted, and is waiting for the next policy
%           update (which may not happen for a while, for example, if
%           policy is frozen fro a release).

%  State G: Not policy decision
%  Stage H: Time out, no formal policy language ever proposed
%  State I: referred to TC
%  State J: referred to debian-devel
%  State K: Rejected by delegates

%         Now, coming back to procedures. Should all states in the above
%  state machine be tracked in the BTS? From past experience, even
%  though the old policy process had state tracking via the BTS, most
%  people never did track state B -> state D changes in the BTS. Things
%  like state C tracking in the BTS seem like a lot of red tape.

%         User tags would be great for tracking flow of a change through
%  the state machine, though. We can leave severities well enough alone:
%  the severity can reflect a consensus of how critical a policy change
%  is, in the eyes of the proposer and debian-policy regulars, and
%  unrelated to the progress the proposal has made, which is tracked by
%  usertags and user categories.

%   1. Trivial policy updates that don't change the substance of policy
%      (markup changes, fixing typos) will be made by the policy
%      maintainers as they see fit.

%   2. Flaws/Defects  in policy should have a normal or important bug
%      filed against policy in the BTS.  The usertag is the one reserved
%      for "State A", unless 4. applies.

%   3. Gaps in policy should be filed with a wishlist priority. Usertag
%      is still the one reserved for "State A", unless 4. applies.

%   4. If a solution for the gap or flaw is also proposed initially, the
%      usertag is the one related to "State B", skip to 6.

%   5. Discussion on the gap/defect happens, and a tentative solution is
%      proposed. the usertag is the one related to "State B".

%   6. Input is solicited from domain experts, as needed.  Time is
%      allowed for such experts to provide input.

%   7. Once three developers or one of the policy maintainers (other than
%      the proposer) have indicated they support the proposed change,
%      usertag corresponding to stage E is added.

%   8. Formal policy language is specified for the bug. usertag
%      corresponding to stage D is added.  At this point, this Bug gets
%      sent to the policy-announce mailing list. Final reviews and
%      discussions start.

%   9. Policy should be designed to meet the concerns of all developers,
%      and all suggestions should be taken into account as far as
%      possible.  If the policy maintainers are satisfied with the
%      proposed change, the patch will be committed to the policy
%      revision control system. The usertag corresponding to "State F"
%      is added.

%  10. If policy maintainers think that the proposed change does not
%      meet the concerns of all maintainers, or no formal language or
%      solution can be agreed upon, the may forward the issue to the TC or
%      the developer body; usertags for States H, I, or J may be added.

%  11. If at any point the policy maintainers are not satisfied with
%      the proposed change or the reasoning behind it, they may make
%      suggestions tag the bug "wontfix", and/or close the bug. The
%      usertag  for state K is added.

\end{document}

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: t
%%% End: 
