This the story of how I got banned (temporarily) from GitHub.
(I don’t blame GitHub support, this was entirely my fault.)
I had a list of really cool apps that I would like to package in F-Droid (some of them from the really nice Android Experiments collection).
And I had some free time this morning so I decided to go through my list to check which apps complied with our policy and create issues to ask each app author if they would be OK with publishing the app in F-Droid.
But because I was a bit in a hurry, I copy-pasted the same minimalist message containing a simple question and a link to the F-Droid website (thinking the website was self-explanatory).
By looking back at it, I now realize that my messages really lacked context and how it looks like I’m spamming some random repositories to promote my niche app store.
This is not a correct way to contact app authors and gives a bad reputation to F-Droid, and I apologize for that.
So here are a few guidelines that I should have applied to myself:
Don’t assume every app author knows what F-Droid is: explain what we do, how we package apps and what it means for the author.
Don’t copy-paste messages: explain why we want to package this app specifically.
Don’t create 30 issues on the same day.
Also, I had to explain to GitHub support how we handle RFPs and they don’t really like the fact that we contact repository owners that didn’t ask us to package their app:
If the GitHub project owners have initiated a request, and you are responding to their request by opening an issue in their repository, then we are okay with the activity. However, if you are seeking out apps that you are interested in, and you are initiating the request via an issue in their repository, we would consider it a prohibited activity.
So we might have to rethink how we handle these things.
What if the request is initiated by a member from the wider community? Where would you draw the line between a general community member and an F-Droid contributor? What if the requester is a contributor to both projects (but not an owner)?
I completely understand their reaction, which is appropriate, and I also see their point, but outright banning this type of request unless it is initiated by the project owner is overly harsh, and frankly ridiculous in the face of the open community we’re trying to foster.
I think it’d be okay if requests are initiated by a variety of people, and stay low-volume and polite, following the guidelines in your post. That is to say, people should do everything in their power to be the opposite of a spammer.
Also, thanks for writing down your experience here.
“Also, I had to explain to GitHub support how we handle RFPs and they don’t really like the fact that we contact repository owners that didn’t ask us to package their app:”
Github is not FSF or Richard Stalman lol.
When a code is free software, you have the right to package the code, change the code…
Just inform them that the sofware will be packaged in F-Droid, if they could give futher support…
I think GitHub should reconsider their approach on that matter. I don’t remember any repository owner being annoyed by us asking or considering our question as spam.
I also think that the person that opened the RFP should open the issue on GitHub (or otherwise ask the app author) and that we should avoid doing it.
@Rudloff If you would like an app to be included in F-Droid you should also start by opening an RFP and then ask the app author linking to the RFP issue.
This also brings up a related issue about adding new apps to F-Droid. One big advantage F-Droid has over other app stores is that we are a community curated app store. That means that a community of people tries to include the valuable apps, and exclude the cruft. So just because there is an RFP and it is easy to add an app, does not mean that we should add that app. Otherwise, this can easily overwhelm the f-droid.org collection with apps that one person requested, and are basic so easy to add. Also, apps that are only interesting to a few people are a lot less likely to be maintained. That will make this even worse, if there are lots of basic, unmaintained apps only used by a few people.
This is not an abstract concern. We were already there, but then the MD5 signature thing inadvertently triggered a big purge of unmaintained packages that few people cared about. We can also learn from Debian. There are lots of procedures about also removing unmaintained packages. Basically there is an assigned maintainer for every package. If packages are abandoned, they can be removed from Debian.
Unfortunately, a lot of the good apps out there are a lot harder to package and maintain. So that means its a lot less fun to work on them.
@hans And trollers who will destroy apps reputation.
Reviews will avoid this. Maybe by giving strong weight to F-Droid team members voting.
It’s a F-Droid ranking in fact.
@Rudloff Back to the topic of GitHub & F-Droid RFPs, I think what truly failed your process was the volume copy/pasting, which, of course, would flag GitHub’s spam detectors. In truth, I don’t think what they said about proactive RFPs actually reflects GitHub’s stance iff said requests aren’t spammed. It does help, too, to spread stuff out over time.
E.g., here’s a great exchange that I initiated & @Izzy expanded, with a dev who’s preparing an app for RFP:
I’ve a number of those, &, in most cases, not only does GitHub completely ignore the RFP, the dev is thankful (& probably a li’l flattered ), especially when I continue to follow through w/ them in the process. Of course, that would be difficult if I were to try that on 30 apps simultaneously, but ~5 or so @ once is really no problem.
A bit OT: @Rudloff Most of those Android Experiments have no licensing info, so, if you’re following up on those RFPs (as you should), try to RFE/help the devs on that. I usually point toward Github’s own tool:
Encouraging toward F-Droid-compatible licensing would be useful (obviously ).
With OpenDNSUpdater, the dev already had almost abandoned the app even – and TPS and I convinced him to pick it up again. That issue is a good example also for what @Rudloff wrote as it meets the condition of explaining what F-Droid is. To me it even looks a bit like that was the final trigger for the dev
Interpreting Github’s response: we (F-Droid) can hardly be held responsible if “some user” opens an issue asking for F-Droid inclusion. So when the issue is already there, it should be perfectly fine for us to “jump in” and help. So where there’s no such issue yet, we just need an independent … oops
I’m not sure what this comment means. If we did have a system for ranking apps, it wouldn’t actually work until after the apps are added, or am I missing something?
But sure, if we know that an app is popular, it should be prioritized.
we had a good discussion and come up with a good plan for a Popularity Contest. Some of the required pieces are already in place. It just needs someone to implement it:
), especially when I continue to follow through w/ them in the process. Of course, that would be difficult if I were to try that on 30 apps simultaneously, but ~5 or so @ once is really no problem.
).
