While acknowledging the Snapcrafters organization’s adoption criteria[1][2] for snaps, I’m wondering if there are any benefits if we do have one that accepts everything(well not exactly everything, but with a lower criteria like completing most of the tasks in the Snapcrafters Template).
As far as I can see there are a few benefits:
Multiple people can take care of the adopted snaps, which is marginally better than an unmaintained snap which only a single person has the control
Multiple people can deal with the problem if certain snap’s upstream has a problem with certain snap’s presentation without escalating it to the snap store
We can also enforce some kind of quality assurance to the snaps, including but not limited to proper store metadata, upstream update checker, proper interface detection, and automatic building and publishing
Last but not least, we do have a final dumping ground if the initial packager really have no interest in maintaining their snap in long-term basis(which is sad, but still possible)
A decentralized, centralized place for interested snap packagers to host and maintain their snaps, together, with lower adopting criteria for completing most of the tasks in the Snapcrafters Template
Adoption criteria
Completing most of the tasks in the Snapcrafters Template, however, the following are the must:
An attempt to contribute the snap to the upstream
An attempt to transfer the snap to the Snapcrafters
A call for testing topic and a release announcement topic in the snapcraft forum
The snap must be at least launch-able and all known issues filed in its issue tracker
The snap must not infringing any law, including but not limited to copyright, etc.
Who has the repo write access?
All individuals that have their snaps adopted by this organization will gain write access to the corresponding snaps’ repository.
They will also be invited to optionally join the organization, which will gain write access to all snaps owned by the organization.
The implementation
A new GitHub organization to-be-created, probably named:
There is a lot of common sense in joint work on snaps, like some Debian teams maintain packages. First idea it to change GitHub vendor lock-in to open source platform. Second is to have maintainers guidelines and monitoring who does what across the tree with no ability to erase history to reduce risk of data loss if some accounts are hijacked.