[Dev] Community goals for Chandler 0.7

Aparna Kadakia aparna at osafoundation.org
Wed Jan 11 16:19:58 PST 2006


Alec,
At the end of 0.6 release we created a community QA page that's linked 
from Chandler's 'Get Involved 
<http://chandler.osafoundation.org/getinvolved.php>' page and it pretty 
much covers all the items you have below. Check this out:
http://wiki.osafoundation.org/bin/view/Projects/CommunityQA

We have broken down items for non-coders as well as coders. I agree we 
could use as much help from people just trying out features in Chandler 
manually as we could with automated tests. Automated tests are meant to 
help in the long run in terms of regression testing etc but it can never 
completely offset the number of bugs human interaction can find visually.

Aparna

Alec Flett wrote:

> I have a very quick-entry-point goal: More QA.
>
> 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!
>
> Alec
>
> Ted Leung wrote:
>
>> As part of the planning for Chandler 0.7, I would like to set some 
>> community goals.   Please reply to this message if you have ideas for 
>> things that you'd like to see happen or things you think we ought to 
>> try.
>>
>> Here's a few to get things started:
>>
>> * Start a community project to write import/export converters for 
>> popular file formats
>> * Change the Chandler build so that we can get Chandler distributed 
>> by the various Linux distributions
>>
>> Ted
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/dev
>
>
>------------------------------------------------------------------------
>
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
>Open Source Applications Foundation "Dev" mailing list
>http://lists.osafoundation.org/mailman/listinfo/dev
>  
>


More information about the Dev mailing list