• Diff for "how-can-i-help/Ideas"

Concept

We envision a package in Debian that provides a program, how-can-i-help, that shows you ways you can help Debian.

Initially it would be very similar to rc-alert and wnpp-alert but more verbose about everything not assuming that you know what are you looking at.

Ideas

Of course, almost all of these ideas fall off the apt-get hook idea already in place which is more oriented to engage with people that is already engaged somehow

These can be showed on demand and a have a good default when invoking the program

• order wnpp, rc and newcomer bugs: programs that you regularly use, then installed, then the rest
• Generate a file of the computer that can be gathered to be able to show this stats for your "server farm" ordered by number of occurrences. (Ex. These rc bugs affects all your computers, these packages that you use are orphaned in half your servers...)
• output friendly to create a gui tool
• List other oportunities to collaborate. Maybe this really belong to a webpage, but I think it would be really nice if the flow could start from the program, like launching the bugreport/bts or linking to concrete non-package chores, translations, art, press or whatever. Even tho technical stuff is easier to convey in a program, id like to be able to point to this program to any kind of newcomers.
• Translation metrics for installed languages. Concrete link to start helping your language
• Centric place with chores that people can post to with expiration date. (ex. this need to be done before a year, this are the requirements, this is what you should know to do it and this is what im willing to help you with). This could be listed in the tool as well
• list next BSPs. BSP are a great way to get you feet wet and should be promoted out of the freezes as well
• list qa expecific chores
• some bugs that affect you (not rc) ordered by time/random, language (laguage tag in bugs defaulting to the one in debtags for package?). BTS and bug triagging would also benefit of some string explaining the status of the bug.(ex. waiting for upstream to change license, find bug in code, etc) This along the date + person that last touched bug would help feel more satisfiying the unrewarded task of triaging bugs (aka duplicate efforts, opening bugs tabs, reading whats going on and figuring out whats next if somebody has done that already)

Metrics

Probably will be useful to come up with metrics so we can measure how useful the program is.

Possibly useful metrics:

• How often is the program used? (If we know that, we can measure the effect of campaigns to get the word out about the program.)