I agree we need more people. I just want to say a point of
clarification: for usability issues and improvements, we definitely need
a maintainer. For security issues, I will always make the time if no
one else if available.
I agree we need more people. I just want to say a point of
I like this idea very much!
I have touched this (very briefly) as well in my recent nextcloud-conf talk: https://bubu1.eu/talk.pdf (p11).
One other thing I’d like to add is that it would already help a lot if we got more people maintaining even one or two apps (their own or one they frequently use). Currently out of necessity almost every fdroiddata maintainer has to become a generalist, being potentially resposible for hundreds of different apps. I’d very much like to spread that burden on far more shoulders.
@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.
It looks like there is consensus on this, so I’ll move forward with step 2: Gathering a list of roles that exist within F-Droid.
I’ve created a wiki for this purpose here: F-Droid roles
and duh, I forgot to mention:
Communications Team - TWIF, mastodon, blog posts, etc.
As for the (current) F-Droid roles page, how would we call the teams that
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.
The page mentions two maintainer groups:
- 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
Calling it F-Droid client maintainer rather than F-Droid app maintainer will make it clearer, I think.
Definitly! And implies the repository (
fdroidclient). Which brings to mind, again by repository association:
- F-Droid server maintainer
- F-Droid website maintainer
data are already covered by the “Repository maintainer” group). And where does the TWIF fall into? Website?
All in favor of the two bulleted additions, rais your … uh … emoticons
Here’s another “job” title/function… advertiser
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 it probably won’t make sense to break things down by “Website”.
Instead, the website will fall under:
- “Communications” - TWIF and posts
- “Localization” - handling all the translation stuff
- backend/tools - turning the index into pages for each app
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.
Someone asked in private for clarification on the level of detail we need. I thought the answer was useful enough to post in public:
Just pretend we’re a company looking for people to hire, and we’re now writing the job ads.
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
Start by taking a look at these MergeRequests for new apps maybe: https://gitlab.com/fdroid/fdroiddata/merge_requests
Hello dear community,
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 ?
Your first assignement, fix this: https://f-droid.org/wiki/page/fr.xgouchet.packageexplorer/lastbuild :))