Differences between revisions 2 and 3
Revision 2 as of 2017-04-29 07:48:12
Size: 2687
Editor: PaulWise
Comment: gift usertag has been renamed to newcomer tag
Revision 3 as of 2023-09-28 09:06:49
Size: 2685
Editor: PaulWise
Comment: cleanup
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
We envision a package in Debian that provides a program, {{{how-can-i-help}}}, that shows you ways you can help Debian. There is now a package in Debian that provides a program, {{{how-can-i-help}}}, that shows you ways you can help Debian.
Line 5: Line 5:
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. It is similar to rc-alert and wnpp-alert but more verbose about everything not assuming that you know what are you looking at.
Line 8: Line 8:
Line 12: Line 13:
 * order wnpp, rc and newcomer bugs: programs that you regularly use, then installed, then the rest  * order WNPP, RC and newcomer bugs: programs that you regularly use, then installed, then the rest
Line 14: Line 15:
 * 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.
 * output friendly to create a GUI tool
 * List other opportunities 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 reportbug/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.
Line 17: Line 18:
 * 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  * 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 others are willing to help you with). This could be listed in the tool as well
Line 19: Line 20:
 * 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)
 * list QA specific chores
 * some bugs that affect you (not RC) ordered by time/random, language (language tag in bugs defaulting to the one in debtags for package?). BTS and bug triaging would also benefit of some string explaining the status of the bug. (for example waiting for upstream to change license, find bug in code, etc) This along the date + person that last touched bug would help feel more satisfying 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)

Concept

There is now a package in Debian that provides a program, how-can-i-help, that shows you ways you can help Debian.

It is 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 opportunities 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 reportbug/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 others are 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 specific chores
  • some bugs that affect you (not RC) ordered by time/random, language (language tag in bugs defaulting to the one in debtags for package?). BTS and bug triaging would also benefit of some string explaining the status of the bug. (for example waiting for upstream to change license, find bug in code, etc) This along the date + person that last touched bug would help feel more satisfying 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.)