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

[Andy A. <ag...@sb...>]

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.

So, Ed, you may have gotten a flood of messages regarding tracker item
changes. That's what this is all about. I have items with the "wxConvey :
wxXml" Category automatically getting assigned to you, Ed.

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.

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

Andy