1 From: Chris Frey <cdfrey@foursquare.net>
2 Date: Thu, 2 Jul 2009 18:18:32 -0400
3 To: barry-devel@lists.sourceforge.net
4 Subject: Be a Barry Deputy (or, How to volunteer)
8 I know there are people who want to volunteer, but sometimes don't know
9 exactly what to do. Sometimes, they know what to do, but they have to
10 wait on me for some critical architecture. And other times, they do
11 something, I see their efforts, and then I forget their names in the
12 future when similar tasks arise. I do my best, but sometimes it is easy
13 to overlook some facts or details, and it is not meant to be taken
16 As project lead, it is my duty to make volunteering as easy and clear
17 as possible. And volunteers should be recognized for their work.
19 I've come up with a list of roles that people can volunteer for. The idea
20 behind these roles is that a number of volunteers can be my eyes and
21 ears in areas that I don't have the time to monitor consistently.
22 Also, to support the notion that "with many eyes, all bugs are shallow."
24 These roles will be added to the end of the AUTHORS file. Each role
25 can be filled with one or more people, working as a team. They then
26 report to the mailing list, to keep me up to speed, or to feed patches
27 or testing data to me.
29 I'll add people's names to the AUTHORS file the first time they report
30 on one of these roles and request to be added to the list. Being on
31 the list means you intend to continue volunteering for that role.
33 Suggestions are welcome.
43 Some distros release very early, and it is possible to follow
44 along their development cycle. These distros include Fedora,
45 Ubuntu, and Debian. There have already been some people reporting
46 bugs on pre-release versions of distros, and that has been very
47 helpful in ironing out kernel bugs, etc. I'd like to make this
48 a formal role for those who already live on the bleeding edge.
50 These deputies would test the latest stable version and the
51 git version of Barry on pre-released distros and report any
52 bugs they find to the mailing list, along with patches if
53 available, and links to documentation if something new is being
54 introduced in that distro.
59 These deputies would simply checkout the latest git tree and
60 compile everything, on as many machines as they have, and
61 report any compile errors to the list. This could be
65 Documentation Page Maintainer
66 -----------------------------
67 These deputies would claim one page from the web docs or
68 one man page, and keep it up to date with any changes in
69 the related program. Sometimes new features in command line
70 tools such as btool, bjavaloader, etc. get lost in the
71 cracks, and don't get documented right away in the man page.
72 These deputies would watch for changes in the program options,
73 and either submit a patch to the docs, or just a reminder
74 that we've forgotten something.
79 These deputies would watch the downstream distro packager repos
80 and report any relevant patch and send it to the list.
81 This is to avoid bugs being fixed in a distro package
84 Not all patches are suitable upstream, but I can easily decide
85 that if I know about the patches.
87 They could also report relevant bugs they see in downstream
88 bug trackers, and report them to the mailing list.
90 And finally, on distros such as Debian stable (when it becomes an
91 issue), they can submit small maintenance patches for fixes in
92 upstream that can be used downstream. Examples of such changes
93 are ppp modem fixes, new chatscripts, or new Product IDs.
98 These deputies would test every feature on new Blackberry models
99 and desktop software, and report what can be done with them
100 that you can't do on the previous model.
102 There should be a document listing all these features so
103 we know what to test against.
106 Tech Support Liaison Officers
107 -----------------------------
108 These deputies would camp out on their favourite web forum
109 (sourceforge tracker included) answering questions, and
110 repost them on the mailing list if they don't have an answer
116 These deputies would watch for the latest developments in distros
117 and report if Barry's binary packaging is doing something
118 that is out of date or deprecated, and how it should be
119 done better. For example, they could run lintian on Ubuntu,
120 or report RPM build errors on strict OpenSUSE builds, or
121 report general directions such as the recent deprecation of HAL.
124 External Link Maintainer
125 ------------------------
126 These deputies would maintain a web doc page of external links
127 of documentation, reverse engineering blogs, and anything
128 technical related to the Blackberry... and encourage
129 such links to be posted to the mailing list. If others shared
130 such links on the mailing list, they would pick them up and
131 update the documentation.
134 Device Compatibility List
135 -------------------------
136 This deputy would maintain a list of Blackberry devies known
137 to work or not work with Barry. Reports from testers would
138 be incorporated into a single page summary that would include:
140 - version of firmware
143 - what databases are reliable for backup and restore
144 - what devices charge well
145 - name of tester, and link to their original mailing list