On Sun, 16 Jan 2011 12:44:10 +0000 Chris Carr <rantingman@gmail.com> wrote: > > Bug triage doesn't need huge amounts of package-specific skills. It > > just needs the people doing triage to be able to cooperate with the > > maintainer(s). > [snip] > >> Is there an obvious way for people willing to do grunt work to help > >> such teams (as opposed to the highly skilled work done by the core > >> people in the maintenance team) to find that grunt work and begin > >> contributing? > > > > Skills can be learnt, taught and developed - the missing component > > is the person who can work alongside the existing team without > > lecturing those in the team and without pestering the team with > > newbie questions. That's fun for the whole team. > > > > The more hard-pressed the team, the harder it is for new people to > > learn the ropes. There's no answer to that problem except that new > > people must want to learn, not lecture. > > > > No matter what your expertise, the packaging team has different > > expertise and everyone needs to get along to fix the actual problem. > > I have had two experiences in this area: wanting to help get dmraid > support added to d-i (2003-7) and wanting to add a new package to > debian (#576029, which is now ready for upload). I am a competent > sysadmin, but a novice programmer. In both cases I ended up > "pestering the team with newbie questions" because of the > complexities of d-i and of packaging, respectively - not because I > was unintelligent or unmotivated, nor because I had failed to read > the available docs. Sounds like the docs need to be improved.... (no surprise there). Perhaps the best thing to do at this stage is to seek a different forum for your newbie questions - mentors.debian.net may be one place, a local LUG may also be useful. Google, as ever, is your friend too as most of these problems have been solved before. > I would welcome advice on how non-programmers should approach working > with volunteer maintainers who have vastly more knowledge and skill > than we do. Filing bugs about the docs and discussing things at a level of "these docs don't make sense to me as a newbie because the docs are, as ever, written by the packaging team who know all the hidden assumptions already" will make more sense than asking the questions to the maintainers directly. Providing a test case which is accessible to the maintainers is usually a huge bonus. Nothing makes bugs harder than the maintainer(s) not being able to reproduce your problem themselves. Maybe it would be a simple script or even an account on the machine concerned. > To me it seems a bit like trying to play squash with a > pro: it's no fun for them, but if you don't have anyone intermediate > to practice with, you'll never get better. These things take time. (Then you might be able to be the intermediate to help the next newbie.) If your motivation doesn't last as long as the amount of learning required, there are plenty of other issues to select. > I would happily volunteer to do bug triaging on certain packages, as > I am certain I possess the skills to do this. Is it as simple as > emailing the maintainer(s) and offering? My whole point in all of this is that the entire process takes time and the current team will have a lot more time for you if you put in the time to bring yourself up to speed with the team. Meritocracy - do the work and those who you ask for help will have more time for your questions. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpbKBnhn3vSs.pgp
Description: PGP signature