4 ms·
But many OS projects are desperate to get help from non-coders. For example: * documentation written by non-native speakers (and lazy/busy devs in general) ne
by jankotek 10y ago
But many OS projects are desperate to get help from non-coders.
For example:
* documentation written by non-native speakers (and lazy/busy devs in general) needs a lot of editing and corrections.
* complete artwork (logos, inverse logos, web template, slides...)
* sorting and answering bug reports. About 70% of bugs opened on Github are just simple questions
* project management, release schedule, maintaining work queue...
- dom0 10y ago> * documentation written by non-native speakers (and lazy/busy devs in general) needs a lot of editing and corrections. ftfy: > * documentation needs a lot of editing and corrections. Good docs can be as much work or more as the project itself.
- nebabyte 10y agoExcept that the former describes useful PRs that could be confidently contributed by someone who doesn't know the deep technicals of the item being documented, while the latter could just as easily need such knowledge. Bad docs can be just as much an impediment to useful work as bad PRs to the project itself. Someone not confident in submitting a code PR might similarly not wish to try and 'clarify' something they don't actually understand.
- dom0 10y agoCan you elaborate? I only removed the qualifier ("written by non-native / lazy / busy devs"), since almost any text that has not been copy-edited can be improved by doing just that, which requires little or no domain knowledge. Also don't undervalue documentation feedback. Everyone makes first contact with a project only once, and the feedback of this "onboarding" can be invaluable and point to critical shortcomings of documentation.