Iāve read quite a few complaints about PRs not being merged in a timely manner or being ignored, but itās not always because of company policy and some of the problems could be solved by putting in place a solid QA team.
One QA person per-app doesnāt scale well at a lot of apps. Thatās also not taking into account that some apps get way more traffic than others.
Do you have any further ideas on your second point?
Thatās actually a very good point. At ownCloud there is a proprietary self developed web app used by the employed QA team.
The platform basically allows you to select a branch / pull request and it starts a new docker container on the internet for you and within a few seconds you can access your test instance at {identifier}.foo.com.
I think it makes very much sense to build up something like that as well. But certainly as open-source, plus we need to make some more thoughts on who is hosting the platformā¦ Whether everybody should have access, after all they can do all kind of mischief with the platform etcā¦
Probably some kind of GitHub login like we have in the forum and a check whether the user is a member of the Nextcloud community would solve such a problem.
A person can be in charge of more than one app, but at least one person needs to be assigned to a supported component and track PRs.
Oh, OK. You mean it should be someoneās responsibility; not necessarily the only responsibility. Absolutely. Iād argue that we should have 2-3 people on an app to get consensus and to work across timezones.
This could be done as a new iteration of the work I am doing for the per user demo for Google summer of code for owncloud. It is using kubernetes.
Just wanted to add that before we might duplicate work.
There is already a list of maintainers for each app and server component: