Re: [convey-developers] sourceforge tasks, bugs, feature requests

[Ed B. <edb...@ca...>]

Thanks, Andy. Comments below...

On Sat, 9 Aug 2003 13:37:48 -0700
 "Andy Ames" <ag...@sb...> wrote:
> I reorganized the sourceforge project.
> 
> We now have tasks, but only under the wxXml subproject.
> Items on the task
> list are items that will be implemented. Also, in the
> wxxml source docs, I
> referenced the task # from the appropriate class or
> method using the @todo
> tag. See any of the wxXml headers for an example.
> 
> The Bug and Feature Request trackers now have the
> following Categories:
> 
> Convey Java
> wxConvey
> wxConvey : wxXml
> wxConvey : wxJab
> 
> They're self-explanatory.
Yes they are. Nice organizing.
> 
> They way I've been conceptualizing this whole process is
> like this:> 
> 1) Tasks
> 
> The subproject owner is responsible for creating and
> managing tasks in their
> subproject, as well as assigning tasks (assuming of
> course the person they
> assign a task to agrees). Anyone can add comments to a
> task to give their
> feedback or insight.
> 
> I imagine, though, that the discussions will occur on
> this mailing list, and
> then the conclusions get pasted into the task by the
> subproject owner.
> 
> Each Task will also be referenced from the source code
> doc "@todo" items.
> This may not be necessary, but it certainly helps remind
> us of upcoming
> changes when we're browsing the code.
> 
> 2) Bugs
> 
> Anyone can submit bug reports on a subproject. The
> subproject owner is
> ultimately the person who determines if the bug really is
> a bug, and if and
> when it will be fixed. Again, the subproject owner can
> leverage any other
> developer's time and resources to accomplish this.
> 
> Each bug that is determined to be valid by the subproject
> owner will also be
> referenced from the revelant source docs using the "@bug"
> tag. This can be
> done whether or not the subproject owner intends to fix
> the bug.
> 
> 3) Feature Requests
> 
> Anyone can submit these. The subproject owner manages
> these items through
> their lifecycle like they do with bugs.
> 
> Feature Requests would be the place where developers make
> suggestions to the
> subproject owner regarding their subproject.
> 
> Feature Requests, once accepted by the subproject owner,
> are turned into
> task items.
> 
> 4) Developers Mailing List
> 
> This, of course, is where most of the discussions begin.
> Also, many
> dicscussions from here will be filtered down into a task,
> bug, or feature
> request, as necessary.
> 
> 5) Conclusion
> 
> There's a hierarchy of content flow:
> 
> --- Mailing List
>   |
>   --- Bug
>   | |
>   | ---Task
>   |
>   --- Feature Request
>     |
>     ---Task
> 
> Content flows from the root to a child. At any stage, the
> content may be
> rejected as being inconsequential. Before entering the
> Task node, the issue
> gets the subproject owner's full approval.
> 
> Of course, this is somewhat simplified, since content can
> be generated
> offline (verbal discussions) or by non-team members
> submitting items. BTW,
> the only non-team members likely to submit something are
> other developers
> using our product/APIs in some way. Convey client users,
> OTOH, are likely to
> want something a little simpler. Ed's idea was to have a
> bug report dialog
> box in Convey. This could send a message (via Jabber) to
> some place
> (chatroom?) where we pick it up and filter it down or
> content flow
> hierarchy.
> 
Yes, I haven't finished this way of bug reporting and am
wondering if this would be too much to add at this late
date.

> Anyway, sound good? I think this works for now. When we
> start bringing on
> more developers, we can get more specific about this
> process.

It sounds fine. We don't really have that many developers
so the process probably only needs clarifying on a
as-needed basis. When we find ourselves spending alot of
time clarifying the process, then we should sit down and
spend a bit more time on formalizing the process.
Thanks, Andy.