[VOTE] Approve the attic proposal

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

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

I vote +1.

I wrote:

+1 in favor.

Hi Thorsten & Emiliano, all,

Thorsten Behrens píše v Čt 24. 03. 2022 v 00:20 +0100:

calling for an email VOTE on the below final version of the Attic
Proposal. The vote runs for 72 hours, starting now.

Thank you for this effort, +1 from me.

All the best,
Kendy

Hi all,

(...)

• 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”;

I'm curious why there is not only push function is disabled but also
pull function. Does this mean that there is no 'git clone' available too?

Regards,
Andreas

Jan Holesovsky píše v Čt 24. 03. 2022 v 20:07 +0100:

> calling for an email VOTE on the below final version of the Attic
> Proposal. The vote runs for 72 hours, starting now.

Thank you for this effort, +1 from me.

Oops, meant to +1 from this email address :slight_smile:

[Sorry about that, I've mis-configured after a reinstall...]

All the best,
Kendy

Hi Andreas,

Andreas Mantke píše v Čt 24. 03. 2022 v 21:24 +0100:

> • 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”;

I'm curious why there is not only push function is disabled but also
pull function. Does this mean that there is no 'git clone' available
too?

It is "pull request" as a term known originally from GitHub, not
"pull", so "git clone" is supposed to be available; it would make no
sense without that of course.

GH explains "pull request" as:

"Pull requests let you tell others about changes you've pushed to a
branch in a repository on GitHub. Once a pull request is opened, you
can discuss and review the potential changes with collaborators and add
follow-up commits before your changes are merged into the base branch."

All the best,
Kendy

Hi,

calling for an email VOTE on the below final version of the Attic
Proposal. The vote runs for 72 hours, starting now.

Thanks to all involved in the discussion ..

and +1 from me,

Cor

Hi Andreas, all,

Andreas Mantke wrote:

> • 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”;

I'm curious why there is not only push function is disabled but also
pull function. Does this mean that there is no 'git clone' available too?

That seems to be a misunderstanding. A "pull request" in git(hub) lingo
means asking an upstream git project to merge a change.

A readonly clone is going to be available for atticized projects.

Cheers,

-- Thorsten

Hi Thorsten, all,

Hi Andreas, all,

Andreas Mantke wrote:

• 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”;

I'm curious why there is not only push function is disabled but also
pull function. Does this mean that there is no 'git clone' available too?

That seems to be a misunderstanding. A "pull request" in git(hub) lingo
means asking an upstream git project to merge a change.

A readonly clone is going to be available for atticized projects.

I summarize:  for a attic project  no git push and pull request are
available, only git clone and git pull.

Thus it is not possible to make a contribution or a potential
contribution for such a project within TDF resources.

The attic proposal expects for the de-attic process (extraction):

• 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;

• 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;

Because it is not possible to make a pull request or to work on a branch
of the attic project on TDF resources, the work on that project has to
be done somewhere else.

The developers which work on that project need to organize their work
inside that new environment. They will already organize their workflow
and communication channels.

And thus the question pops up, why they should invest their (volunteer)
work time to ask for moving the project onto TDF resources, change their
workflow etc. and transfer everything onto TDF resources and under the
hat and control of TDF.

Thus if TDF moves a project to the attic a steel door is locked behind
it with a lot of locks. It will be unlikely that such a project will get
back to live inside the TDF environment.

Regards,
Andreas

Hello,

The Board of Directors at the time of voting consists of 7 seat holders (not including deputies). In order to be quorate, the vote needs to have 1/2 or more of the Board of Directors members, which gives 4.

A total of 4 Board of Directors members have participated in the vote.

The vote is quorate.

A quorum could be reached with a simple majority of 3 votes.

Result of vote: 4 approvals, 0 abstain, 0 disapprovals.
Decision: The proposal has been accepted.

Florian

Abstaining from voting on it as while the text could be a starting point it seems to make it clear that whatever goes in the "attic" will never come out of it as explained very well by Andreas Mantke:

https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00373.html

While the text has been written to take out of the way LOOL there have been no follow ups to requests to evaluate what else we are hosting which should or should not be put in the "attic".

Before anything is put in the "attic" we should make an analysis of what we are hosting, open repositories for 12 months (if they have been frozen) and promote them to see if anyone starts contributing and then, after the 12 months period has expired, evaluate if the repositories should be archived for good.

Ciao

Paolo

Hi Andreas, all,

let me address your questions as how I can summarise the intentions &
discussions we've had, over the past months. Other board members can
chime in and explain their take.

Andreas Mantke wrote:

Thus it is not possible to make a contribution or a potential
contribution for such a project within TDF resources.

Not while the project is in the attic, no. That is the entire point
for an attic - communicate to the world out there, that currently at
least, this very project is not actively developed at TDF.

The Readme as suggested in the proposal text gives some concrete ways
how to get it out of there though!

Because it is not possible to make a pull request or to work on a branch
of the attic project on TDF resources, the work on that project has to
be done somewhere else.

Yes. Unmaintained projects are a risk to have in a software supply
chain, so experiments to re-vitalise should happen on the side. If
then still someone uses that in production, at least TDF is not the
upstream source for it.

The developers which work on that project need to organize their work
inside that new environment. They will already organize their workflow
and communication channels.

The easiest (and for many developers, most convenient & accustomed)
venue for that are gitlab or github. To me, that is zero obstacles.
You can even give both platforms a remote git repo to clone from,
that's, like, two clicks and a paste.

And thus the question pops up, why they should invest their (volunteer)
work time to ask for moving the project onto TDF resources, change their
workflow etc. and transfer everything onto TDF resources and under the
hat and control of TDF.

My personal take is - that is very little effort, compared to actually
developing. But of course it helps if there's community interest, in
pushing/advocating the re-opening.

In the past at least, there was interest in having projects hosted at
TDF. It comes with good name recognition, and a large and diverse
community. I suspect the positive marketing effects would be
noticeable, when reviving an atticised project, and therefore (as a
developer myself) don't see a problem here.

Thus if TDF moves a project to the attic a steel door is locked behind
it with a lot of locks. It will be unlikely that such a project will get
back to live inside the TDF environment.

I don't think that follows at all (and in fact has very little to do
with realities out there - every github project would then be
essentially locked, since one needs to fork it to be able to commit).

For developers willing to revive a project, finding a place to host a
repo is trivial. Doing the development work and getting up to speed in
large code bases, is where the challenges lie.

Cheers,

-- Thorsten

Hi Paolo,

Paolo Vecchi wrote:

Abstaining from voting on it as while the text could be a starting point it
seems to make it clear that whatever goes in the "attic" will never come out
of it as explained very well by Andreas Mantke:

https://listarchives.documentfoundation.org/www/board-discuss/2022/msg00373.html

I've just answered Andreas, and I believe he's not describing a
real-world problem, for actual developers of the kind of code hosted
at TDF.

Andreas has used github before, with forked repos from TDF's main
ones, and gihub issues for bug tracking. It really does not seem to be
a barrier.

Before anything is put in the "attic" we should make an analysis of what we
are hosting, open repositories for 12 months (if they have been frozen) and
promote them to see if anyone starts contributing and then, after the 12
months period has expired, evaluate if the repositories should be archived
for good.

We should look at each request to atticize on its own merits. The vote
on the process has just passed (it's the ESC's and the board's job to
propose projects).

An aside: let's please continue the discussion with a separate subject
if there's a need; but ideally as a new thread. the vote here has
concluded.

Cheers,

-- Thorsten

Hi Thorsten, all,

(..)

The developers which work on that project need to organize their work
inside that new environment. They will already organize their workflow
and communication channels.

The easiest (and for many developers, most convenient & accustomed)
venue for that are gitlab or github. To me, that is zero obstacles.
You can even give both platforms a remote git repo to clone from,
that's, like, two clicks and a paste.

that is only the manual part. This may be not very difficult (e.g. if it
happens in [nearly] the same environment). But you didn't consider the
mental aspects. Why should a developer / a group of developers take
their work / their freedom back under the control of the ESC / TDF and
had potentially to frighten the attic process again (especially if they
work as volunteers in their spare time)?

And thus the question pops up, why they should invest their (volunteer)
work time to ask for moving the project onto TDF resources, change their
workflow etc. and transfer everything onto TDF resources and under the
hat and control of TDF.

My personal take is - that is very little effort, compared to actually
developing. But of course it helps if there's community interest, in
pushing/advocating the re-opening.

In the past at least, there was interest in having projects hosted at
TDF. It comes with good name recognition, and a large and diverse
community. I suspect the positive marketing effects would be
noticeable, when reviving an atticised project, and therefore (as a
developer myself) don't see a problem here.

I'd recommend not to gear about towards the past. I'd have a look on the
LOOL process and you get the opposite.

Thus if TDF moves a project to the attic a steel door is locked behind
it with a lot of locks. It will be unlikely that such a project will get
back to live inside the TDF environment.

I don't think that follows at all (and in fact has very little to do
with realities out there - every github project would then be
essentially locked, since one needs to fork it to be able to commit).

But if you fork a Github repo you could make a pull request to the
upstream project. This will be blocked for an attic project by the proposal.

Regards,
Andreas

Hi Andreas, all,

Andreas Mantke wrote:

But you didn't consider the mental aspects.

I did, but I still believe that's quite minor compared to the actual
development effort.

The policy as it stands now is a compromise between a number of needs
(and people's ideas), where there's some barrier for moving a project
into the attic, and a corresponding barrier for getting it
back. Additionally, there were requests that new projects from
commercial players should come with certain commitments (and those
naturally transfer over into de-atticization).

Beyond actually showing development (and finding support at TDF), most
of the more burdensome prescriptions in the policy are merely
advisory. So the ESC and/or the board can make pragmatic decisions,
should an obvious case be brought forward.

But if you fork a Github repo you could make a pull request to the
upstream project. This will be blocked for an attic project by the
proposal.

Sure. But you said not being able to create pull requests leads to
insurmountable barriers for new development. I dispute that; and the
meta-pullrequest (which this policy specifies) is to submit a git
repository hosted & developed outside the TDF realm, via the
de-atticization process.

Cheers,

-- Thorsten

Hello,

Hello,

The Board of Directors at the time of voting consists of 7 seat
holders (not including deputies). In order to be quorate, the vote
needs to have 1/2 or more of the Board of Directors members, which
gives 4.

A total of 4 Board of Directors members have participated in the vote.

The vote is quorate.

A quorum could be reached with a simple majority of 3 votes.

Result of vote: 4 approvals, 0 abstain, 0 disapprovals.
Decision: The proposal has been accepted.

once I looked over this decision making process, I find it striking that
only four BoD members participated. And also is remarkable that among
this participants are only long time TDF members and members which have
are part of LibreOffice ecosystem development companies or their
contract partner.

And because the starting point for this attic proposal (and its first
use case) is LOOL (online) it is not the best management, if members
with a potential CoI around this first use case participate. I'd expect
they abstain.

But independent from this, it is sad to see that there seemed to be
already no consent inside the board between the members connected to
LibreOffice ecosystem companies and the other members at the start of
the new BoD term.

Regards,
Andreas

Hello,

Hello,

The Board of Directors at the time of voting consists of 7 seat
holders (not including deputies). In order to be quorate, the vote
needs to have 1/2 or more of the Board of Directors members, which
gives 4.

A total of 4 Board of Directors members have participated in the vote.

The vote is quorate.

A quorum could be reached with a simple majority of 3 votes.

Result of vote: 4 approvals, 0 abstain, 0 disapprovals.
Decision: The proposal has been accepted.

once I looked over this decision making process, I find it striking that
only four BoD members participated. And also is remarkable that among
this participants are only long time TDF members and members which have
are part of LibreOffice ecosystem development companies or their
contract partner.

And because the starting point for this attic proposal (and its first
use case) is LOOL (online) it is not the best management, if members
with a potential CoI around this first use case participate. I'd expect
they abstain.

Indeed, should be that way.

But independent from this, it is sad to see that there seemed to be
already no consent inside the board between the members connected to
LibreOffice ecosystem companies and the other members at the start of
the new BoD term.

It's not the first time that happens, previous term had a lot of that.

However, I believe that a consensus does not necessarily have to be reached. One can disagree. What is of utmost importance is to promote the best decision for TDF.

This all goes hand in hand with the refusal to hire developers within TDF.

Hi Andreas,

Hello,

Hello,

The Board of Directors at the time of voting consists of 7 seat
holders (not including deputies). In order to be quorate, the vote
needs to have 1/2 or more of the Board of Directors members, which
gives 4.

A total of 4 Board of Directors members have participated in the vote.

The vote is quorate.

A quorum could be reached with a simple majority of 3 votes.

Result of vote: 4 approvals, 0 abstain, 0 disapprovals.
Decision: The proposal has been accepted.

once I looked over this decision making process, I find it striking that
only four BoD members participated. And also is remarkable that among
this participants are only long time TDF members and members which have
are part of LibreOffice ecosystem development companies or their
contract partner.

And because the starting point for this attic proposal (and its first
use case) is LOOL (online) it is not the best management, if members
with a potential CoI around this first use case participate. I'd expect
they abstain.

That the attic proposal has been pushed to archive LOOL, IMHO, is clear but is there any CoI at this stage?

That's a vote on the text, which still has room for improvement, not a vote to archive LOOL.

I proposed to open up the repository for 12 months and see if the community is still interested in bringing it forward or not and then, non CoI'ed directors, could vote on it's archival or not.

But independent from this, it is sad to see that there seemed to be
already no consent inside the board between the members connected to
LibreOffice ecosystem companies and the other members at the start of
the new BoD term.

Sorry but it seems like there are visions for the future of TDF that sometimes diverge quite a bit and yes heated discussions still happen.

I think it's very important that members of the community participate more so that all members of the board understand which direction our community want us to follow.

Regards,
Andreas

Ciao

Paolo

Hi Daniel, all,

Daniel A. Rodriguez wrote:

This all goes hand in hand with the refusal to hire developers within TDF.

I don't see where that should have happened. See also Paolo's answer.

Cheers,

-- Thorsten