Dear directors,
calling for an email VOTE on the below final version of the Attic
Proposal. The vote runs for 72 hours, starting now.
Changes since v2.1:
* corrected mistakes found during Monday board call
* light touch-ups for English
* aligned the readme text suggestions with the changes in the prose
above
Best, Thorsten
-%<------------------------------------------------------------------
## Introduction
It can happen, within a huge project like LibreOffice, that parts
of the project worked on by the community will become obsolete or
superseded by other projects. The following proposal will deal
with the need to let the code (and/or other forms of text related
to the code) be publicly available, while setting the correct
expectations around its availability, suitability for a
production environment, quality and security.
## What is the “attic”?
The “attic” is a special area of TDF's infrastructure where part of
the code/documentation/translations, which is not being actively
developed, can be stored. This will help to set the correct
expectations on its development status, while not losing its
fundamental trait of being open source (so its code must be
publicly available).
In the present proposal, the “attic” would be a single host
inside TDF's infrastructure, available via HTTP/HTTPS protocols,
responding to a URI similar to:
https://attic.documentfoundation.org
## Specificity of the “attic”
This “attic” space will have, at a minimum, the following characteristics:
• It is supported by Git – the well known VCS developed initially by
Linus Torvalds and used to share the sources of the Linux
kernel. Being supported by Git will ease forking of the code
contained there;
• Any repositories inside it will be made “read only”, so no “push” or
“pull request” mechanisms will be available: this allows changes to
the code to be shared as it was the last time it was “atticisized”;
• Anonymous access to the repositories has to be made the default
access method: we want code present in the “attic” to be always
available to everyone;
• It should have a recognizable URL – or internet address, less
technically: this allows for the code present to be clearly
separated by other actively-developed code;
• A specific text explaining the nature of the code, its
“deatticization” requirements and how to get support for the code
inside the repository needs to be present in the README of every
repository. The text of these disclaimers and the deatticization
requirements will be discussed further on in the proposal. Regarding
contacts to get support, the idea is to provide quick and ready
information on who/where to ask for anything related to the code in
the repository.
The proposed implementation of this space is by using git-http-backend [1].
The proposal has already been evaluated by the infrastructure team, and
the overhead for maintaining such a solution will be “negligible”.
## Considerations about the approval procedure for atticization/deatticization
As per the Statutes of the Foundation, the Board of Directors (BoD) should
be the ultimate decision-making body of the Foundation; thus it has
technically the last word on the approval or the refusal of an
atticization/deatticization proposal.
If we analyse the matter at hand, we recognize that there is another codified
body inside TDF that is directly composed by the technical part of the
community and, as such, should have more insights and knowledge on the parts
of the project that are proposed to be atticized/deatticized; that body is
the Engineering Steering Committee (ESC).
As such, a common and shared understanding of the political and technical
impacts of the atticization/deatticization proposal has to be reached by the
two bodies, all together, and this understanding should be condensed into a
unique, unambiguous preference towards approval or disapproval.
The leanest approval process would then be: the ESC expresses its
preference, and the BoD agrees with the ESC. The proposal is then officially
accepted or refused by the BoD, according to the preference expressed.
If this doesn't happen, a shared discussion in a public meeting with the
members of both bodies is highly recommended; the goal of such
consultations would be to understand and underline weaknesses and threats of
the proposal, and eventually to get to a unique preference.
Whatever the means of the consultations are, and if there is no clear
preference for an outcome, but the BoD is called to decide anyway, it has to
provide an official written report on the merits of the decisions, the
decisions taken, and a mitigation plan for the hard blockers identified
during the discussion.
## Atticization process
The Engineering Steering Committee (ESC) of TDF, the Board of
Directors (BoD) or one or more of its Directors can propose the
“atticization” of a part of the project. That proposal will have to be
voted on successfully by both the ESC and the Board of Directors, as per the
procedure described in the previous section.
For an eventual deatticization procedure, the ESC will mark the
project under atticization as either small, medium, or large in terms
of code size and complexity.
After the approval of the atticization proposal, the specific code proposed
(mostly, entire Git-based repositories) will be then effectively atticized
by the infrastructure team.
Other than moving the repository to the "attic", these other
changes will be needed:
• Deactivation of specific -dev or -users mailing lists;
• No new binary releases will be provided (older releases will persist
in the download archive);
• Changing eventual specific category on Bugzilla to “Atticized repo –
please do not use” (needs to be checked by TDF's team);
• Possibly disable relevant Ask/Discourse categories (needs to
be checked by TDF's team).
## Deatticization
A part of the project that is actually present inside the “attic” can
be moved back into active development, whenever sufficient interest
around the code emerges.
## Deatticization requirements
A repository can be deatticized when it reaches the following requirements:
• A publicly available repository has to be present, collecting new
modifications to the initial project. This repository needs to be
based on the initial atticized repository;
• The modified code has to be open source/free software under an
OSI-approved license;
• A sufficient number of developers [2] have committed changes to the
forked repository, ideally not all of them affiliated to the same
entity;
• Every developer should have pushed 5-10 non-trivial commits over the
span of at least three months;
• The deatticization proposal has to be supported by those active
developers, and by at least one member of The Document Foundation;
• At the discretion of the ESC or the BoD, if parties involved in the
development of the project are commercial entities and as a prerequisite
of approving/refusing the proposal:
* A formal agreement must be published outlining the scope, benefits
and responsibilities of both the parties and TDF.
* This agreement should state any significant impacts on TDF, its
development community, and users - both negative and positive.
## Deatticization procedure
The deatticization has to be requested from either the ESC or the
Board of Directors; the ESC will provide a technical clearance for the
deatticization, as well as any needed corrections to the project to
comply to specific development customs of TDF community and to adhere
to the conventions practiced at TDF.
A well-written proposal for the deatticization can help the ESC and the BoD
to quickly identify requirements, changes needed and thus speed up the
approval; some samples might be provided to haste the process.
Once clearance has been granted, both ESC and BoD will vote on the
deatticization of the specific repo, as illustrated by the above section
(cft. "Considerations about the approval procedure for atticization/deatticization").
If the vote turns out affirmative, the implementation part will be
handed over to the infrastructure team, which can, based on common sense:
• Import the forked public repository;
• Or move the repository from the attic to Gerrit altogether, and apply the
needed corrections.
If needed, a new mailing list, along with Bugzilla and Ask/Discourse
categories will be instantiated.
## Proposed text for the nature of the code
The following text is proposed to be included in the README of any
atticized repository:
---
This repository contains FLOSS code that is not maintained and/or
actively developed. The code provided here is *NOT READY FOR
PRODUCTION*, as it lacks updated security auditing (and probably
contains insecure code) and Quality Assurance. Releases are *NOT*
provided for this code any more.
---
## Proposed text for the deatticization requirements
The following text is proposed to be included in the README of any
atticized repository:
---
This repository might be moved to active development under TDF’s
supervision through a specific procedure.
Please check that your modifications match the following requirements
(all of which need to be fulfilled):
* modified code is present in a publicly available Git repository
* modified code is released with a free/open source license
* at least {1|3|6} developers, ideally not from the same entity,
modified the code
* modifications efforts to the code are qualified as 5-10 non-trivial
commits for each developer over a period of three months
* modified code is actively advocated by its developers and at least a
member of TDF
If the requirements are fulfilled and you can guarantee to continue to
develop the modified code, please get in touch with TDF's ESC and
Board of Directors.
The full procedure is available at [Insert URL to a wiki page with the
procedure here].
---
[1] (https://git-scm.com/docs/git-http-backend)
[2] 1 for small, 3 for medium, and 6 developers for a large project
-%<------------------------------------------------------------------
