Thanks for all your kind words.
other system
Laptop, SSH, paper :). I wasn't a heavy mobile user in general and
only got interested in cellphones when they became more PC-like. So
with 3.5 years in F-Droid, I only have about 4-5 years of actual
mobile phone usage. Coming from a more old-school unix environment,
reverting back.
Does it go as deep as hosting/infrastructure for the f-droid website,
forums, wiki, etc?
I only worked on fdroiddata (with small contributions to documentation,
website and server), so others like client and forum and core
infrastructure are not affected at all. Not saying that their
situation is perfect, so if you want to chip in, there always
a lot of work to do.. regardless of "branch" 
roles and responsibilities
Basically it was adding and updating apps. Apps are described by meta
information and buildscripts stored in simple text (migrating to yaml)
files, so it's actually easy to get used to. While there are some really
sophisticated (and sometimes) weird apps out there, most apps are either
based on gradle or have an option to output a gradle build (like newer
cordova/HTML apps). So you can copy an adapt old builds in most cases.
There is no fixed list of "duties", so its up to whatever you
encounter while doing maintenance. Here is a list of what I have come
up with:
Monitor the fdroiddata commits for apps that updated their version
code (but don't update the app itself): Look into that and add the
actual build information.
Monitor the wiki for failing builds, investigate and ideally fix
the build
Monitor the "request for packaging" queue and try to add new apps
(the fdroid import tool has become quite convenient to use).
Talk to upstream, if he wants to include the app, and explain why
e.g play-services are hindering an inclusion etc. Also: Try to
keep fdroiddata as clean as possible. If an app requires a complex
set up, you can most likely upstream some if not all of your
changes: Most app devs test and build on their system only, some
have a "works for me, so its your problem" attitude, some are
really greatful, since you actually point out issues that they
just warent aware of.
Propose changes to fdroidserver tools, like updating the installed
SDKs, NDKs and other build-tools. Adapt the binary-scanner and
importing tool. While fdroidserver is largely handled by others,
app maintainers are users of the tool and see if anything is
broken or if tasks they are doing manually get repetitive and
can be automated.
Documentation changes to the (hopefully soon to be re-launched)
website.
Talk to upstream, other devs and users on IRC, forum, and answer
incomming mails.
Should we start drawing up a list of now un-maintained packages?
We never came to a state where we have lots of maintainers for one
specific app. Instead most of the contributors just work on whats
seems relevant right now, regardless of what app. So the list
would be rather lengthy We maintain a list of apps that need
updating and apps with broken builds in the wiki, having a look
at the commits that only upgrade the versioncode instead of adding
new builds also helps and is most of the time more reliable.
(Sidenote: The current state of failing builds at the wiki -- see
https://f-droid.org/wiki/page/Category:Apps_with_failing_builds --
is not representativ, i think its caused by a bug, see
https://gitlab.com/fdroid/admin/issues/38 )
There are always people willing to help new maintainers over at
fdroid and #fdroid-dev. I haven't left those, and I hope Boris
won't either.
Yep, I will stay on IRC as well, so when there are questions that
I can answer, I will do by best to do so