Alec Flett wrote:
Davor Cubranic wrote:
One possible way to make it easier to track things without hampering
free flow of ideas might be to somehow link the wiki and Bugzilla. For
example, one could start by filing an enhancement in Bugzilla. If it
is considered too fuzzy or too far ahead of the current plans, the
discussion could be moved to the wiki, and a page created in a special
area, for example "Jungle/Bug1234" or something like that. The
Bugzilla entry is meanwhile marked "LATER" or even "INWIKI", so it
doesn't have to ever show up in the developers' queries, but it's easy
to schedule it for further consideration at a future date, or reopen
once the discussion in the wiki has produced an implementable proposal.
For everyone's benefit: Its general bugzilla practice to use the Target
Milestone field in mozilla to set the target to "Future" - and the
expectation is that developers will more or less ignore these Future
bugs until they are marked back to a real milestone
Alec
+1 to Alec's comments here, we are indeed actively using the Target
Milestone field and "Future" is the target for enhancement requests that
are not currently scheduled for a release.
You can link from the wiki to a bug by using this notation when editing
the wiki page:
Bug:1234
The wiki will create a bug link. You can link from a bug to the wiki by
pasting the url in either the bug comments or in the URL field.
Anyone is welcome to use the Jungle as a wiki scratchpad for developing
ideas -- that is what it is for! We've found that the wiki is a bit
challenging for a discussion though -- perhaps best for writing up an
idea, maybe collaborating with a few others. The list turns out to be
better for an extended discussion. In other words, the wiki is good for
capturing a proposal and being the record of the current state of the
proposal, and the list is better for discussions about the proposal.
To repeat Mimi's point about welcoming proactive ideas, we're definitely
open to proposals and ideas from any interested party -- a good idea is
a good idea, whoever proposes it. ;) Just as we would do with code
submissions, we want to make sure that any design proposal has merit and
fits with the overall goals and design of Chandler before adopting it.
As Mimi mentioned, we're trying to work out a process that allows for
collecting a variety of ideas, and then evaluating and iterating on
those ideas. The process for incorporating design ideas will differ from
the processes we will use for patch code submissions.
We have a few next steps that should help:
+ Refine the wiki organization and process for capturing proposals, so
that they don't get completely lost on the wiki
+ Document Chandler's goals and design more clearly and make that easily
accessible (not lost in the wiki), so that people have that information
when participating in disucssions and formulating proposals
+ OSAF discussions about the design (as well as development) should be
held publicly on the list so that people who are not in the building in
SF can participate effectively
We're working on it! We appreciate the recent activity on the list, it
has been very constructive.
Cheers,
Katie
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
