F-Droid job board

jobs
roles

#12

@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:


#13

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.


#14

@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.


#15

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


#16

and duh, I forgot to mention:

Communications Team - TWIF, mastodon, blog posts, etc.


#17

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?

#18

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.


#19

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 :wink:


#20

Calling it F-Droid client maintainer rather than F-Droid app maintainer will make it clearer, I think.


#21

Definitly! And implies the repository (fdroidclient). Which brings to mind, again by repository association:

  • F-Droid server maintainer
  • F-Droid website maintainer

(rfp and 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 :rofl:


#22

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. :slight_smile:

Also important trait, able to understand that they might never merge your PR/MR… :frowning:


#23

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

#24

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.


#25

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.


#26

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


#27

Start by taking a look at these MergeRequests for new apps maybe: https://gitlab.com/fdroid/fdroiddata/merge_requests


#28

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 ?


#29

Your first assignement, fix this: https://f-droid.org/wiki/page/fr.xgouchet.packageexplorer/lastbuild :))


#30

Already done, my PR has been opened for a week https://gitlab.com/fdroid/fdroiddata/merge_requests/3757/diffs


#31

You need a build server locally, so you can run fdroid command and build the apps before anything else.

The Gitlab CI Pipeline does only the linting part.