(gitlab.com looks too much like the new github owned by a private corp, and self-hosting is quite a lot of work, c.f. the experience we had with redmine)
(Bram and ??? already registered Yunohost and YunoHost-apps on framagit)
(Rafi did some tests / moved his apps on framagit ?)
Pieces with hard-coded Github stuff right now :
app.py
app list builder
the issue tracker
simone for automatic PR submission
tartiflette / dash
weblate / yunohost-bot PRs
the general pull request process
vinaigrette / the deb build chain
maybe pieces in the app CI or package check / linter
???
[Organization] Being a sustainable project
Communication about donations / Liberapay :
on the forum
in ssowat / the webadmin
on the website
communication strategy (e.g. which websites to communicate on, each time we have a release / an announcement)
We need somebody (and/or together) to start communicating about the project
Possibilities to gather money:
subventions / public funding
Tango & scan 2019
RIPE
EU / Next-generation internet
crowdfunding
donations
SaSS ?
plug and play backup
consulting on the core (but we need to find people that would be interested for that)
contact big associations
hosting provider (like gandi)
professionnal support
formation ?
We kinda conclude that we should at least setup an association and start looking deeper / implementing some of those.
TODO:
contact kload to know if we cant recycle the old association ? (Done : we cant)
highlight / communicate ways to donate to the project
establish a preliminary budget ? with “steps” ?
subscribe to crowdfunding platforms ?
Idea of a separate wiki for Apps Documentation
Discussion around how to organize the documentation for apps. This is related to the few pages like YunoHost • index which arent really exploited, and about the README in the apps repo which arent displayed to people legitimately not knowing about app’s repo - yet sometimes repos contains important info.
One possibility could be to have the doc pages hosted inside each app’s repo, inside a doc/ folder (in addition to the readme). This could then be imported in the general doc, and/or accessible from the webadmin.