F-Droid job board

,
1

Hi all,

I’ve been thinking that we could use a “job board”. Sure you can just point to the various issue trackers, but I think we can target and attract contributors better when we describe the roles F-Droid has at a higher level, in a similar way to job listings.

Our “Contribute” page and the How to Help document under “Docs” make a stab a this, but could do better at describing the various developer roles. Additionally, these two pages read like different versions of the same document.

The process I have in my head is like this:

  1. Get feedback on whether this is a good idea, take ideas and suggestions
  2. Gather current roles
  3. Design and write the page

What should be on the page

The main page should summarize:

  1. Title and short summary of each role
  2. Summary of skills
  3. Requirements (hardware/tools)
  4. Who are currently filling this position
    (so it’ll double as a “who’s who” in F-Droid)
  5. How badly we need people in this role

Sort by most urgent first.

At a later stage, we might want to add individual detail pages.

Example

(not necessarily accurate)

F-Droid app maintainer

Summary: You oversee development of the F-Droid app, triage and handle issues, review and merge Merge Requests.
Skills: Experience with developing Android apps
Required: Android app developing environment, e.g. Android Studio.

Current F-Droid app maintainers

None. We urgently need a new maintainer for the F-Droid app.

Repository maintainer

Summary: The main repository is built from a collection of metadata. 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.
Skills: (tbd)
Required: (tbd)

Current repository maintainers

Izzy Licaon_Kter

Izzy Licaon_Kter

We could use one or two more people to make response times faster, but nothing urgent.

And so on. This is just a very rough sketch limited by the forum’s capabilities, but I hope you get the idea.

6 Likes
2

I’d wage that whomever wanted to come has came (and gone), and will come… :wink:

3

I think the truth lies more in the middle. If people don’t understand what kind of work needs to be done, they will assume everything is fine and move on to the next project. Think of this as a way to make F-Droid more “sticky”. :wink:

How many people even know we need a maintainer for the F-Droid app?

2 Likes
4

I don’t think this is the issue, as any other app (also server), it needs maintainers.

The metadata part might be a surprise though. :slight_smile:

5

@Coffee Wiki - F-Droid Forum would probably be the best place to @ least test this, I think.…

1 Like
6

@TPS: Thanks for the suggestion! That’s definitely something we could use, although I’d prefer a “real” wiki with more powerful formatting features. I don’t think this thing even does tables…

1 Like
7

It’s not that the app needs more maintainers… It needs a maintainer. @hans can occasionally throw some scraps of time at it, in addition to very specific and goal-directed paid work on the app, but essentially the F-Droid app is currently u n m a i n t a i n e d.

8

I didn’t know that, and given my involvement around here that might say a lot… :frowning:

9

Thanks for proving my point for me. Do you now see why we need a jobs page? :wink:

2 Likes
10

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.

3 Likes
11

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.

1 Like
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:

2 Likes
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.

2 Likes
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

1 Like
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:

1 Like
20

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

3 Likes