Draft text: an "attic" proposal - version 2.0

Dear community members,

Following the discussion on the first revision of the "Attic" proposal, posted here by Thorsten Behrens on December 17th, 2021, gathering the input we received from the community (thanks for the invaluable help provided by everyone who participated!) and as anticipated in the last Board meeting (yesterday, March 7th), Thorsten and I tried to condense the discussion in a new 2.0 version, which I post below for further discussion.

Of course, we are available to further clarify the proposal, if needed, and we eagerly await for your input on this following version.

-%<------------------------------------------------------------------

## Introduction

It can happen, with 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 cope
with the need to let the code (and/or other form of text related
to the code) to 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 infrastructure where part of
the code/documentation/translations can be parked, that is not
anymore actively developed. This will help setting the correct
expectations on its status of development, 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 infrastructure, available in HTTP/HTTPS protocols,
responding to a URI similar to:
https://attic.documentfoundation.org

## Specificity of the “attic”

This “attic” space will have, at minimum, the following characteristics:

• It is supported by git – the well known CVS developed by Linus
   Torvalds initally and used to share the sources of the Linux
   kernel. Being supported by git will ease the 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 the 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 on the code
   inside the repository needs to be present in the README of every
   repository. The text of these disclaimer 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 Infra 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 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 in a unique, unambiguous preference towards approval or disapproval.

The leanest approval process would then be that 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
components 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 as outcome, but the BoD is called anyways to decide, 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 hinted in the previous section.

After the approval of the atticization proposal, the specific code proposed (mostly, entire git-based repositories) will be then effectively atticized by the Infra team.

Other than moving the repository to the "attic", these other
changes will be needed:

• Deactivation of specific -dev or -users mailing list;

• 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” (ed.: needs to be checked by Infra/QA/Ilmari);
• Possibly disable Ask/Discourse pertaining categories (ed.: needs to
   be checked by Infra/Sophie).

## De-atticization

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.

## De-atticization 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;

• At least three different developers 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 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. "Approval procedure for atticization/deatticization").

If the vote turns out affirmative, the implementation part will be
handed over to Infra team, which can, based on common sense:

• Import the forked public repository;

• Or move the repository from attic to gerrit altogether and apply the
   needed corrections.

If needed, new mailing list, 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*
anymore provided for this code.

---

## 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
(which needs to be all fulfilled):
* modified code is present in a publicly available git repository
* modified code is release with a free/open source license
* at least 3 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 3 months
* modified code is actively advocated by at least a member of TDF

If the requirements are fulfilled and you can guarantee to continue to
develop on the modified code, please get in touch with TDF ESC and
Board of Directors.

Full procedure available at [Insert URL to a wiki page with the
procedure here].

[1](https://git-scm.com/docs/git-http-backend)

-%<------------------------------------------------------------------

Cheers,

Hi Emiliano,

Of course, we are available to further clarify the proposal, if needed, and we eagerly await for your input on this following version.

  Proposal seems reasonable.

This “attic” space will have, at minimum, the following characteristics:

  All sounds fine.

## De-atticization

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.

## De-atticization 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;

• At least three different developers 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;

  It would help to have another bullet here:

   * These active developers should all support its de-atticization.

  I think this was implicit, but lets make it explicit =)

The following text is proposed to be included in the README of any
atticized repository:

  Should be included in the README too I think.

  Otherwise, seems reasonable.

  ATB,

    Michael.

the quintessence of he proposal would be that a project will at 99,9% or
more wouldn't get out of the attic state inside the TDF resources. The
barriers to de-attic a project and make it an active project inside TDF
are much higher than setting up / starting a new project.

You ask for at least 3 devs with a lot of very valuable commits to start
the process. But in comparison with the hurdles to run a new project /
idea inside TDF resources there is no balance. A lot of (software)
projects starts and run with only one (or maybe two) developers. If you
put the same burden on them they would never get a go from TDF.

I think a lot of volunteer work for and around LibreOffice would have
been running on TDF resources if you took this criteria as a basis.

The proposal is the start to stop any (volunteer) initiative to revive
of - temporarily - not actively developed / worked on projects.

Everyone who wants to work on such a project from the attic needs to use
resources outside of TDF and I expect the development will stay there
(and will not moved to TDF resources later).

Thus in my opinion it is contrary to TDF's mission.

Regards,
Andreas

Hi Andreas,

thanks for your feedback.

I have to agree with you that the process seems to be too cumbersome and it would very likely lead to the end of the project, so may as well delete it, or to forks that will never come back.

The point here is also to try to understand what the scope of the "attic" would be, apart from locking out LOOL as we haven't got a list of other projects that we could/should archive.

During the first discussion the Android Viewer has been proposed for archival to then discover that mostly one developer (Michael Weghorn) is actually looking after it so we have a good example that some may take interest on a project if it's open for contributions.

Probably before we decide to put a project in the "attic" it would be a great idea to understand which projects we are hosting and then decide what to do as the rules should be the same for all and we should avoid another LOOL situation without clear rules in place.

As plenty of time has passed by since LOOL has been forked I would even propose to just re-open the repository and let the community decide if they are actually interested in contributing to it.

We may discover that the community is actually interested in contributing to a LOOL which is unlikely to reach features parity with other similar products but that is good enough for some use cases where basic features and a lightweight component is needed. If a community starts forming around it then we could compile it and make it available with the relevant warning of not being commercially supported as it planned before it was forked.

If within 12 months we see that there is no interest at all then we may as well tarball LOOL and make it available for download for historical reference.

Ciao

Paolo

Hi Andras,

the quintessence of he proposal would be that a project will at 99,9% or
more wouldn't get out of the attic state inside the TDF resources. The
barriers to de-attic a project and make it an active project inside TDF
are much higher than setting up / starting a new project.

That is true. On the other hand: is it reasonable to compare a new project with one that is in attic state?
For a new project - and I think TDF will adopt projects all too swift - you create a stage so that there is a place to grow, prove oneself.
When a project has been paused at some moment, that will not have been done without thinking, consideration, extra efforts to avoid etc. as well.
So based on this, one not make conclusions on the current proposal by 'comparing' the cases.
For me the clear demands in the proposal are to prevent a situation where projects restart without a good change on success, which is IMO quite relevant for TDF's good name.

Cheers,
Cor

Hi Andras,

the quintessence of he proposal would be that a project will at 99,9% or
more wouldn't get out of the attic state inside the TDF resources. The
barriers to de-attic a project and make it an active project inside TDF
are much higher than setting up / starting a new project.

That is true. On the other hand: is it reasonable to compare a new project with one that is in attic state?
For a new project - and I think TDF will adopt projects all too swift -

               will _not_ - that should read of course.

I tend to agree. I don't think making it trivial to deattic something
by applying a set of superficial commits to a very large code base
which don't achieve meaningful change while f.e. unaddressed security
issues mount up, creating a sort of zombie would be a good idea.

wrt the proposals exact number of devs and commits, I could imagine
that on getting atticed a project is categorized into small, medium,
large with 1, 3, 6 devs required to de-attic if there is genuine
concern about the proposed bar being too high vs a new from scratch
project.

Hi Cor, all,

Hi Andras,

the quintessence of he proposal would be that a project will at 99,9% or
more wouldn't get out of the attic state inside the TDF resources. The
barriers to de-attic a project and make it an active project inside TDF
are much higher than setting up / starting a new project.

That is true. On the other hand: is it reasonable to compare a new
project with one that is in attic state?
For a new project - and I think TDF will adopt projects all too swift
- you create a stage so that there is a place to grow, prove oneself.
When a project has been paused at some moment, that will not have been
done without thinking, consideration, extra efforts to avoid etc. as
well.
So based on this, one not make conclusions on the current proposal by
'comparing' the cases.
For me the clear demands in the proposal are to prevent a situation
where projects restart without a good change on success, which is IMO
quite relevant for TDF's good name.

and with the proposal the Android Viewer had to be put the attic and
wouldn't currently get the chance to get out of this state (because only
one developer looking for it).

I created two projects for TDF infra in 2011 (and two further in 2012
and 2013). If you'd ask for the same commitment to start / run this
projects as for de-attic a project, this projects wouldn't have been
supported / used by TDF.

Thus I'm happy that never used TDF resources for the source code of my
projects and could fork and further develop this projects without
explicit permission of TDF.

I don't think the attic proposal will help TDF to save it's reputation.
It's a clear statement of setting further barriers to volunteer work.

Regards,
Andreas

Hi,

and with the proposal the Android Viewer had to be put the attic and
wouldn't currently get the chance to get out of this state (because only
one developer looking for it).

Fair point. One could think of a way that the activity/nr of devs asked, has a relation with the initial project/project from the past.

Emiliano, Thorsten, what do you think?

I created two projects for TDF infra in 2011 (and two further in 2012
and 2013). If you'd ask for the same commitment to start / run this

so that's not the aim, as I explained.

projects as for de-attic a project, this projects wouldn't have been
supported / used by TDF.

Cheers,
Cor

Hi Paolo,

Paolo Vecchi píše v Po 14. 03. 2022 v 17:07 +0100:

I have to agree with you that the process seems to be too cumbersome
and
it would very likely lead to the end of the project, so may as well
delete it, or to forks that will never come back.

Interestingly when I've read the de-atticization part of the attic
proposal, I had the feeling it goes well with your proposal that when a
commercial entity wants to contribute a project, they have to go
through extra scrutiny? What has changed, please?

As plenty of time has passed by since LOOL has been forked I would
even
propose to just re-open the repository and let the community decide
if
they are actually interested in contributing to it.

With my developer hat on (ie. not Board, not Collabora), I'd like to
point out that you should consider the implications of potential or
real security issues. How do you want to force the community to fix
those? [I mean, who will be the actual people actually fixing those?]
What if the re-opened repo gets a CVE?

We may discover that the community is actually interested in
contributing to a LOOL which is unlikely to reach features parity
with
other similar products but that is good enough for some use cases
where
basic features and a lightweight component is needed.

Still with my developer hat on, I think you underestimate the
complexity of the Online editing problem; the programming was just
completely different 25 years ago (I think you said you used to be a
developer then?).

The problems that the Online has to sort out are complex; like
extremely complex; like nobody-25-years-ago-could-imagine-how-much
complex: Lots of asynchronous communication, performance implications
(on many levels - in C++, in C++/JS combination, in JS, on the
network), limitations of JavaScript, limitations of various browsers,
and more. And solving these problems is painful, there are no good
tools to debug the C++ / JavaScript combination, developers who love
C++ hate JS & the other way around, etc.

In other words, from the development point of view, there is no "basic
features and a lightweight component" possible for the approach that
COOL / LOOL is using.

All the best,
Kendy

hi Andreas,

and with the proposal the Android Viewer had to be put the attic and
wouldn't currently get the chance to get out of this state (because only
one developer looking for it).

that's a bad example: the Android Viewer is in the core.git repository.

there is no practical way to "move it to the attic" - in the hypothetical case, i'm pretty sure it would be considered too much effort to disentangle a dead project from core.git and there would just be a commit that deletes the code, as has happened for multiple large pieces of obsolete code in the past (just this year i happily deleted 2 WebDAV UCPs).

Hi Jan,

Hi Paolo,

Paolo Vecchi píše v Po 14. 03. 2022 v 17:07 +0100:

I have to agree with you that the process seems to be too cumbersome
and
it would very likely lead to the end of the project, so may as well
delete it, or to forks that will never come back.

Interestingly when I've read the de-atticization part of the attic
proposal, I had the feeling it goes well with your proposal that when a
commercial entity wants to contribute a project, they have to go
through extra scrutiny? What has changed, please?

Nothing has changed at all.

As already explained also to Allotropia in regards to their WASM project I asked if they could officially present their project to TDF in a page or 2 where they also state what part of the project hosted at TDF will be made available for free to the community in full respect of our statutes and mission to lead by example and show that commercial contributors are very welcome, we don't want to complicate things but the relationship should be clear from the beginning to protect each others interests.

That's the same thing that should have happened with LOOL to clarify what type of relationship was there between TDF and the commercial contributor but the commercial contributor decided to clarify it in its own way.

As plenty of time has passed by since LOOL has been forked I would
even
propose to just re-open the repository and let the community decide
if
they are actually interested in contributing to it.
With my developer hat on (ie. not Board, not Collabora), I'd like to
point out that you should consider the implications of potential or
real security issues. How do you want to force the community to fix
those? [I mean, who will be the actual people actually fixing those?]
What if the re-opened repo gets a CVE?

A bit of a shame that LOOL's repository was blocked when we had a bug bounty going on as maybe it would have discovered other security issues but yes we are all aware that there are CVE present in there and it would be up to those that start working on it to look at them and fix them.

We may discover that the community is actually interested in
contributing to a LOOL which is unlikely to reach features parity
with
other similar products but that is good enough for some use cases
where
basic features and a lightweight component is needed.

Still with my developer hat on, I think you underestimate the
complexity of the Online editing problem; the programming was just
completely different 25 years ago (I think you said you used to be a
developer then?).

I used to be a developer and stopped about 25 years ago as I fancied taking on new challenges.

It's true that through the 80s and 90s software development was different but I can assure you that there were levels of complexity that aren't that different from today's systems and the tolerance for errors were probably a lot narrower.

The problems that the Online has to sort out are complex; like
extremely complex; like nobody-25-years-ago-could-imagine-how-much
complex: Lots of asynchronous communication, performance implications
(on many levels - in C++, in C++/JS combination, in JS, on the
network), limitations of JavaScript, limitations of various browsers,
and more. And solving these problems is painful, there are no good
tools to debug the C++ / JavaScript combination, developers who love
C++ hate JS & the other way around, etc.

I bet there are quite a few older developers that would tell you that 25/30 years ago we could imagine those level of complexities as in substance nothing much has changed. I would go as far as saying that you have a lot more tools and information that we had back then and that it was probably much more difficult to handle communication and code optimisation, when we had to deal with X.25 networks, modems and a few MB of RAM, than it is now.

So, yes, I do fully understand what you are talking about.

In other words, from the development point of view, there is no "basic
features and a lightweight component" possible for the approach that
COOL / LOOL is using.

Maybe a small number of passionate and capable developers will be able to fix the CVEs and bring LOOL to a state where it could work well with the features left since the fork for those that don't need new fancy features.

The point is that we don't know until we open the repository and let people know that is available with all the relevant warnings.

If no one will take on the challenge within 12 months then we will know that there is no even point to put it in an "attic".

All the best,
Kendy

Ciao

Paolo

Hi *,

Caolán McNamara wrote:

I tend to agree. I don't think making it trivial to deattic something
by applying a set of superficial commits to a very large code base
which don't achieve meaningful change while f.e. unaddressed security
issues mount up, creating a sort of zombie would be a good idea.

Indeed, the proposal had a large project (like core or online) in
mind.

wrt the proposals exact number of devs and commits, I could imagine
that on getting atticed a project is categorized into small, medium,
large with 1, 3, 6 devs required to de-attic if there is genuine
concern about the proposed bar being too high vs a new from scratch
project.

I like this idea. It nicely addresses the problem.

The other option, at this stage (we're discussing a substantially
unmodified proposal here since almost three months!), would be to
first ratify the atticisation part of the text. Those bits have not
received tangible input in a while, and we could finally get the
online repo out of its undefined state.

Cheers,

-- Thorsten

Hi,

Caolán McNamara wrote:

I tend to agree. I don't think making it trivial to deattic something
by applying a set of superficial commits to a very large code base
which don't achieve meaningful change while f.e. unaddressed security
issues mount up, creating a sort of zombie would be a good idea.

Indeed, the proposal had a large project (like core or online) in
mind.

wrt the proposals exact number of devs and commits, I could imagine
that on getting atticed a project is categorized into small, medium,
large with 1, 3, 6 devs required to de-attic if there is genuine
concern about the proposed bar being too high vs a new from scratch
project.

I like this idea. It nicely addresses the problem.

Ah you already made an nice proposal on this matter, Caolán.
Sorry I missed that early in the evening :slight_smile:

Cor

Hi Paolo,

Paolo Vecchi píše v Po 14. 03. 2022 v 20:59 +0100:

It's true that through the 80s and 90s software development was
different but I can assure you that there were levels of complexity
that
aren't that different from today's systems and the tolerance for
errors
were probably a lot narrower.

You really don't have to assure me. I started programming 35 years
ago, I was there in the 80's and 90's, so I can compare with the
present.

Maybe a small number of passionate and capable developers will be
able
to fix the CVEs and bring LOOL to a state where it could work well
with
the features left since the fork for those that don't need new fancy
features.

The most important "new fancy features" are in the area of making the
editing more fluent, optimized & pleasant, do you really think there
are people who don't need them?

The point is that we don't know until we open the repository and let
people know that is available with all the relevant warnings.

It is git, anybody can clone it & work on it if they want. If there
were passionate and capable developers interested in this, they'd be
bombarding the development mailing list with their patches the last >12
months; passionate and capable developers always find their way to get
their code integrated one way or the other.

But I'm not aware of any such patches.

All the best,
Kendy

Hi Kendy,

You really don't have to assure me. I started programming 35 years
ago, I was there in the 80's and 90's, so I can compare with the
present.

If you were a professional developer 35 years ago?

Then you have to tell me how you can look so young as I thought you were in your early 40.

Maybe a small number of passionate and capable developers will be
able
to fix the CVEs and bring LOOL to a state where it could work well
with
the features left since the fork for those that don't need new fancy
features.

The most important "new fancy features" are in the area of making the
editing more fluent, optimized & pleasant, do you really think there
are people who don't need them?

That is always nice but maybe other features are less important to many.

The point is that we don't know until we open the repository and let
people know that is available with all the relevant warnings.

It is git, anybody can clone it & work on it if they want. If there
were passionate and capable developers interested in this, they'd be
bombarding the development mailing list with their patches the last >12
months; passionate and capable developers always find their way to get
their code integrated one way or the other.

But I'm not aware of any such patches.

As people have been told that the project has been forked and LOOL has been frozen I guess that no one bothered sending patches to LOOL.

Maybe if we announce that we will re open the repository, with the due warnings, we will see if some people are actually interested in contributing or not.

All the best,
Kendy

Ciao

Paolo

Hi Kendy, hi Paolo,

a gentle reminder to please keep this discussion on-topic. There's a
new proposal to address Andreas' initial concern. Please interact with
that, instead of discussing a rather tangential & hypothetical topic.

Thanks,

-- Thorsten

Hi Paolo,

Paolo Vecchi píše v Út 15. 03. 2022 v 12:56 +0100:

Then you have to tell me how you can look so young as I thought you
were
in your early 40.

Apparently sports make me look younger, phew :slight_smile:

And happy to share details about my past & present work, contributions
and merits with anybody who is interested in person; a public mailing
list is not the right place.

All the best,
Kendy

Dear community,

I've rolled all suggestions into this (near?) final version. I believe
we're ready to vote on this now.

Changes to v2.0:
* added a half-sentence to clarify that the developers of the forked
   attic repo would need to want it back as active at TDF
* rolled Caolan's small/medium/large project idea into both
   atticisation and de-atticisation text

Cheers, Thorsten

-%<------------------------------------------------------------------

## Introduction

It can happen, with 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 cope
with the need to let the code (and/or other form of text related
to the code) to 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 infrastructure where part of
the code/documentation/translations can be parked, that is not
anymore actively developed. This will help setting the correct
expectations on its status of development, 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 infrastructure, available in HTTP/HTTPS protocols,
responding to a URI similar to:
https://attic.documentfoundation.org

## Specificity of the “attic”

This “attic” space will have, at minimum, the following characteristics:

• It is supported by git – the well known CVS developed by Linus
  Torvalds initally and used to share the sources of the Linux
  kernel. Being supported by git will ease the 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 the 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 on the code
  inside the repository needs to be present in the README of every
  repository. The text of these disclaimer 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 Infra 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 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 in a
unique, unambiguous preference towards approval or disapproval.

The leanest approval process would then be that 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
components 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 as outcome, but the BoD is called anyways to decide, 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 hinted in the previous section.

For an eventual de-atticization 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 Infra team.

Other than moving the repository to the "attic", these other
changes will be needed:

• Deactivation of specific -dev or -users mailing list;
• 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” (ed.: needs to be checked by Infra/QA/Ilmari);
• Possibly disable Ask/Discourse pertaining categories (ed.: needs to
  be checked by Infra/Sophie).

## De-atticization

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.

## De-atticization 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. "Approval procedure for atticization/deatticization").

If the vote turns out affirmative, the implementation part will be
handed over to Infra team, which can, based on common sense:

• Import the forked public repository;

• Or move the repository from attic to gerrit altogether and apply the
  needed corrections.

If needed, new mailing list, 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*
anymore provided for this code.

---

## 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
(which needs to be all fulfilled):
* modified code is present in a publicly available git repository
* modified code is release with a free/open source license
* at least 3 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 3 months
* modified code is actively advocated by at least a member of TDF

If the requirements are fulfilled and you can guarantee to continue to
develop on the modified code, please get in touch with TDF ESC and
Board of Directors.

Full procedure 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

-%<------------------------------------------------------------------