\subsection{Contact information for committers}

One aspect which I did not see explicitly brought up so far is the issue of 
contributors not being easily contactable. While granting someone commit 
access, we should emphasize that the email address used for commits should be 
one that the contributor checks regularly (in the past, I have found after 
attempting to contact a contributor through their listed email address that it 
was an old address that they no longer check regularly).

\subsection{Contributor guidelines}

More generally, there should be a single set of contributor guidelines listing 
what is expected from committers, such as:
\begin{itemize}\itemsep-3pt
\item the coding style
\item the expectation to remain contactable
\item the code of conduct
\item the recommended development style (if there is one)
\end{itemize}
This information is currently scattered across various parts of the 
repository, the webpage, and the Github wiki; having a single document/webpage 
(which may simply be a set of links to the existing places where each of these 
aspects is dealt with in detail) would be useful while inducting new 
contributors. I can help compile such a document if needed.

\subsection{Stable tagging}

I also think we should bring back the practice of tagging stable versions. 
Given the observed tendency to `silence' auto-tests, I don't think this 
tagging should be done automatically (which I think was the previous 
practice). My suggestion would be to synchronize the release of stable 
versions with the PC User Meetings, at which a stable release can be approved 
after going through a checklist (which would be publicly documented 
somewhere). Some examples of items which would be in such a checklist:
\begin{itemize}
\item create a list of currently working samples (which may just be the set 
included in \texttt{pc\_auto-test levels 0--3}) and check that there have been no 
changes to the reference data of these samples that were not approved by the 
maintainers (we should have a policy that every commit changing the reference 
data should explicitly mention which of the maintainers of that sample 
approved it);
\item for all the postprocessing modules (e.g. Python) that have their own test 
suites, check that the tests still pass (these are currently not included in 
the periodic autotests);
\item discuss proposed changes to default values of input parameters, and include 
a list of such changed defaults in the release announcement (we may need to 
come up with a mechanism to propose changes prior to the meeting, which may be 
Github issues or simply a text file somewhere in the repository);
\item if samples which were working in the last stable version are broken and 
cannot be fixed, this should also be mentioned in the release announcement;
\item for all maintainer email addresses listed in the README files of the working 
samples, check that they are able to receive mails from the auto-test servers.
\end{itemize}

While going through such a checklist is a non-trivial amount of work, my point 
of view is that these issues should be dealt with regularly to keep the code 
healthy; stable version tagging is a compromise that acknowledges that it is 
not feasible to do this for every single commit.

