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 On 13/03/2022 16:12, Andreas Mantke wrote:
Am 08.03.22 um 22:54 schrieb Emiliano Vavassori: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.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 -- ## Free Software Advocate ## Plone add-on developer ## My blog: http://www.amantke.de/blog
-- Paolo Vecchi - Member of the Board of Directors The Document Foundation, Kurfürstendamm 188, 10707 Berlin, DE Gemeinnützige rechtsfähige Stiftung des bürgerlichen Rechts Legal details: https://www.documentfoundation.org/imprint
OpenPGP_signature
Description: OpenPGP digital signature
