4 ms·

This is pretty contradictory to 1. my motivations as a maintainer, 2. how to solve (imo) the barriers in having people contribute to OSS 1. As a maintainer I w

This is pretty contradictory to 1. my motivations as a maintainer, 2. how to solve (imo) the barriers in having people contribute to OSS 1. As a maintainer I want my project to work, if a reporter only wants to give a brief description then I am both happy and have the context in order to read it, attempt to understand it and ask the relevant follow up questions. Ideally someone turns up with a test case and patch and I will make that as easy as I can, but its not a requirement for being able to contribute. 2. I did a questionnaire on what prevents people contributing to open source, by far the biggest barriers I found were things that were solved by asking a quick question to a maintainer, people get stuck on what to fix, or how to set stuff up and they want to ask a person and not a mailing list or a chat room, and certainly not a robot policing their filed bugs

reedlaw 13y ago
That sounds like a good process for smaller projects. For larger projects, or projects where developer attention is a precious resource, not so much. For example, look at the detail provided by the issue submitter to the nouveau (open source Nvidia Linux driver) project: https://bugs.freedesktop.org/show_bug.cgi?id=76732 https://bugs.freedesktop.org/show_bug.cgi?id=76732 Not only is there a lot of log output, the submitter took the trouble to run git bisect on the Linux kernel to see at which point the breakage occurred. I'm sure the submitter spent quite a bit of time and has a high level of familiarity with the project and related tools. This will help developers to isolate the problem and provide a quick fix. Without this level of detail, the issue might never get fixed.
- daleharvey 13y ago
  Thats the point, ultra motivated contributors will do this, semi motivated contributors can be coached into it, people that just want their stuff to work may not, but all of it is useful, putting a barrier in front of that is wasting developers time. And I am not speaking solely about small projects, I experience exactly the same thing while working on Firefox OS, at nearing a million 'issues' its definitely not small.

reedlaw 13y ago

That sounds like a good process for smaller projects. For larger projects, or projects where developer attention is a precious resource, not so much. For example, look at the detail provided by the issue submitter to the nouveau (open source Nvidia Linux driver) project: https://bugs.freedesktop.org/show_bug.cgi?id=76732 https://bugs.freedesktop.org/show_bug.cgi?id=76732 Not only is there a lot of log output, the submitter took the trouble to run git bisect on the Linux kernel to see at which point the breakage occurred. I'm sure the submitter spent quite a bit of time and has a high level of familiarity with the project and related tools. This will help developers to isolate the problem and provide a quick fix. Without this level of detail, the issue might never get fixed.

daleharvey 13y ago
Thats the point, ultra motivated contributors will do this, semi motivated contributors can be coached into it, people that just want their stuff to work may not, but all of it is useful, putting a barrier in front of that is wasting developers time. And I am not speaking solely about small projects, I experience exactly the same thing while working on Firefox OS, at nearing a million 'issues' its definitely not small.