We have around 40 issues on docs and after looking at them it indeed looks like a good starting point to ask for help. The blocker is, maybe, the need to learn about SecureDrop before being able to work on most issues. But it’s difficult to presume.
a pointer to the getting started section in which we need to add a link to the style guide + a link to a guide about creating a pull request
explain that being blocked by something (anything) is a valuable contribution that should materialize into a new issue
I’d be happy to draft something along these (to be proofreaded by a native english speaker ;-). And then we could spread it to an audience likely to attract less than 10 contributors but more than 5. There is a good chance they will be blocked by various things that are difficult to effectively anticipate so we don’t want to attract too many people
The plan sounds great! What form do you expect the actual outreach to take? We have the “securedrop” Twitter account, which should be used more for encouraging contributions than we’d managed to date. A tweet would only be a short blurb, so it’d need to link out to a longer guide, similar to @redshiftzero’s hackathon guide: https://gist.github.com/redshiftzero/81779c42b66738c9478e0f8b830f337f
Then pointing everyone to that resource is a great start. Perhaps we should finally start to use the GitHub “wiki” feature to maintain support docs of this nature. Wouldn’t be opposed to linking directly to a Discourse thread, either.
Sorry, by “form” I meant “Tweet, or otherwise?” I’m fine with Twitter, seems the best way to accomplish outreach given that calls on GitHub will only be seen by folks already contributing.
This is a bit further down the line, but if we write up a really great documentation GitHub gist, we could make use of it as part of SD hackathons, and have a smaller “editathon” with it.
Thanks to @dachary for preparing the tagged issues and linking them in the getting started section of our documentation! Let’s monitor how this goes and we can tweet additional calls as we see fit.
pierwill was active on documentation issues and sent pull requests, but they were already contributing before the call for help. The other documentation contributors in the past week are also not new contributors.
I think we can conclude this call for help did not work and try to fix this.
Maybe (just maybe a few contributors clicked on the provided link, browsed the docs issues and did not find something suitable. I browsed all 49 open issues asking myself: As a new volunteer with experience as a technical writer and fluent in English, what issue can I try to fix within the hour ? But I did not find any. There are a few which may be a good fit such as two-factor unification, but only if the person is already very familiar with two-factor authentication terminology which is unlikely. And the language used in the issue description is not authoritative (it does not say must but should) and suggest the first step is to engage a dialog to establish a consensus on which term to use. It may not take very long but is not timeboxed either.
create a dozen documentation issues that can be fixed within one hour (for instance a string replacement) and kindly ask seasoned developers to leave them open and refrain from fixing all of them within the day
Fun fact: minutes after the new easy documentation issue was filled, someone proposed a pull request. Intrigued by the coincidence I asked how that happened and it turns out this is via the GitHub global search, looking for recent issues with the easy label.
@redshiftzero would you mind sending another call for help on documentation, focusing on easy documentation tasks ? This is an kind of scientific experiment and our goal is to figure out if such a call for help reaches at least one contributor. We know these bugs are solvable and attractive to new contributors (thanks to the first spontaneous fix). If nobody fixes any of the three existing bugs within a week after the call, we can conclude this is not the right channel to reach contributors.
All the easy doc bugs were fixed and this is good But I think it does not count for our little experiment because, a) one of them was fixed by a former contributor, b) two were fixed by a GSoC applicant. As a conclusion it looks like the SecureDrop twitter account does not reach potential new contributors. We know the docs bugs are not a blocker, they really are easy and first time contributors had no trouble fixing them.
Is there a way to reach a larger or more targeted audience ?
