@Coffee Thanks for taking the lead on this, I think it’ll be quite valuable. To get back on the topic that this started with, its a great idea to rework the docs and include documentation of roles within F-Droid. I think that Debian has some examples to follow there. I think it could make sense to have the concept of “Teams” in F-Droid, e.g.:
fdroiddata team - manage new apps and updates, etc.
sysadmin team - running infra like buildserver, ci runners, forum, mirrors, etc
client team - work in Android client(s), Privileged Extension, etc
tools team - fdroidserver, buildserver automation, etc.
localization team - manage translation workflow, Weblate, interact with translators
And on a semi-related note, there is the open issue about creating a “consultants” page on the website to advertise our services for hire:
I think blog posts (or TWIF posts) would also be a good place to advertise this. Maybe not the full description, but at least a short description of positions/skills, with a link to the full description.
@nutomic Yes, this is the deeper thought behind it. Once we have a good and up-to-date list of F-Droid roles and their status, we can highlight important vacancies and point people to the jobs page, both via twif and via mastodon.
As for the (current) F-Droid roles page, how would we call the teams that
Integrate new apps from RFPs (i.e. verify the apps build, so when the Metadata file is merged it results in a “real app” and not just a "dummy entry) → Integrator? That would then include e.g. @relan and @rudloff
keep an eye on the Apps to Update and build those new versions?
It’s the same maintainer, as we won’t merge before checking that it builds.
I do try to look at “Apps that failed” when there’s a bit of time, but really, it’s the same thing…failed…to update…MR…RFP…same workflow…same time to put to use.
F-Droid app maintainer: You oversee development of the F-Droid app … → not the one
Repository maintainer: You are responsible for keeping this metadata up to date for one or more apps. This includes such things as where the source code is, textual descriptions, and build recipes. → that’s probably the part you refer to
If these assumptions are correct: must each “Repository maintainer” fit all of them (then I wouldn’t fit in there) – or is it sufficient if all tasks are covered by the group of repository maintainers together (then the both of us together would meet that, with me covering only a part of it)? And should that be pointed out?
Apps to Update: the list is usually quite long (~200 entries). From the tasks to perform (bringing Metadata up to date, add to the build recipes), this again would fit the description of “Repository maintainer”. So should that be mentioned there explicitly in the description, just for completeness and to keep track of it?
I know I could just edit the page – but I prefer to ask for consent first (after all, the change would be public and thus should be correct). Consent given, I volunteer for the edit of course
The person will do, after a new app is added (or one that misses it), stuff like this, or like this, actually just fork the repo, edit the file in Git/hub/lab web editor (put the correct ID, very important :P), look at preview, press submit MR/PR, no Android developer needed.
Also important trait, able to understand that they might never merge your PR/MR…
I think “teams” are at a level of abstraction above “jobs” or “roles”. You apply for a job and not for a team, although you will usually be part of a team.
I want to document the roles, and then we can organize them into teams.
I would like to help. I’m not new to computers but am new to android … Or at least not an expert by any means. I’ve spent 22 years working in surgery and am finally at at a point I can dedicate my time and energy more to my own endeavors. I love puzzles.
I’m recently married (again) and would love to go into better detail over any qualifications i have for this job but the description was a little light lol. All I can say is that I’m willing to learn and I’m dedicated. You may email or call me please. Nakedpwr@gmail.com
I find myself having a few hours a week I could dedicate to helping this project. I can see among other things that the merge request queue is quite large, how could I contribute and help treat things faster ?
I’m guessing there are a few conditions to meet before merging a PR, in addition to the automated Pipeline build ?
