[Dev] Community goals for Chandler 0.7
twl at osafoundation.org
Wed Jan 11 18:06:11 PST 2006
On Jan 11, 2006, at 8:18 AM, Alec Flett wrote:
> I have a very quick-entry-point goal: More QA.
Sure. As Aparna has mentioned, we're kind of underway to do more of
this. One thing I am interested in is how to actually get more
people to participate in QA. Most of what we have now is "let's put
up bugzilla and tell people to go there, and they'll just come".
Except that we don't have a big user base or a lot of momentum. So
unlike one of the highly visible projects, like Firefox or Apache, I
think we actually need to work at getting people to just file a bug
report. If you look at <https://bugzilla.osafoundation.org/
+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=> You'll see that
there are 13 non-osaf bugs (actually less than that) in Bugzilla
since the date of the 0.6 announcement. So we're not exactly
getting a flood here.
> In my experience, this is the easiest way for new contributors to
> get involved in an end-user product - mostly because it means that
> contributors don't have to be coders, and because the granularity
> of the work is very small.
> I know people are constantly going on about how we need more
> automated tests but end-user apps also need a healthy amount of
> human interaction to find things that automated tests are never
> going to find (unless we stop developing chandler altogether and
> just write tests for 6 months) ... i.e. it takes a human to notice
> than when you drag a calendar event into a saturday, that the
> minicalendar turns blue or that the "sync" button gets disabled
> when you stamp an event as an e-mail, then a task, and then unstamp
> it as an e-mail. (don't worry, none of this really happens!)
> Further, there are lots of very helpful things that QA contributors
> can do within the bug system, beyond simply filing bugs.
> 1) manage dupes: finding dupes of existing bugs is very valuable,
> especially as the number of people filing bugs goes up. This
> usually means people looking at bugs that have been filed in the
> last day or so, and looking for existing dupes - this is really an
> art and when done well its rather amazing.
> 2) help narrow down bugs filed by other reports - this involves
> taking existing bugs that may not be well defined, and narrowing
> their scope to exactly what the problem is. Maybe it turns out that
> the minical only turns blue when you're dragging all day events
> that start before the present date? This might involve just asking
> the reporter for more details, or it may involve trying to
> reproduce the bug.
> 3) platform testing - taking bugs that were reported on Mac but
> seem to be cross platform, trying them on Linux, and reporting
> results in the bug.
> I'm sure there are many other helpful things that I'm not thinking
> of but these are the ones that spring to mind. Its rather amazing
> on the mozilla project the way you can file a duplicate bug and it
> gets marked as a duplicate within 2 hours!
More information about the Dev