Thanks for your replies. Here are some straightforward points:
Trac is definitely useful for storing and managing pending issues.
One concern is not to let Trac get marginalized from people that only
read email. Although there is a small team of active maintainers,
there is a very large developer base that will never follow up on
trac, but which will regularly read the mailing list. So important
events in trac should be reported to the mailing list. Other events
can be read via RSS by those who are interested.
We also need a proper way to report an issue to the community. It
seems that a report to the mailing list works best at first, specially
when the issue needs initial feedback. Then, if it turns out to be
enough of a lasting and relevant issue, open a ticket. In projects
I've worked on, the main use of a tracker is to manage issues you
don't want to loose track of (for obvious reasons). Rarely do I see
people using a tracker when an issue gets solved quickly and has only
a short-term impact. In the case of the binary I/O problem reported to
this list, the issue was immediately solved and is already
well-documented in the mailing list, so that no ticket is needed.
Before submitting the issue to vxl-users, I did my homework and
searched both trac and the mailing lists for possible related issues.
If something is well-documented in the mailing list and it doesn't
need to be tracked, the user should still find it.
Just my 2 cents.
On Tue, Aug 4, 2009 at 7:25 AM, Miguel A.
> On Mon, Aug 3, 2009 at 5:45 AM, Ian Scott wrote:
>> Have we reached a consensus, or does anyone even have a proposal about
>> how we use tickets and the mailing lists? It seems to me we are stuck
>> half-way between a webpages/mailing list collaboration strategy and a
>> wiki/tracker strategy.
> I don't see the tracker as a substitution to the mailing list.
> Sometimes there are things that should be discussed in the mailing
> list before deciding/recommending a ticket is opened. Specially,
> support requests or things that appear to be a bug but it is not.
> Other times there are things that can simply go directly to the
> tracker, such as a feature_request or a bug with a patch attached.
> Also, I would always send a note to the mailing list if it is a bug or
> an important issue (with possibly a reference to the ticket).
> I'd say we need a proposal (I'll work on it; read below) on how to
> integrate the tracker with our mailing list workflow and a proposal on
> how to organize and promote the use of the wiki. But again, I don't
> see the tracker taking over the mailing list.
>> There hasn't been a change in the vxl-users-policy, or the front-page of
>> the website to indicate where problems should be routed, and this is
>> confusing for users, and at least this maintainer.
> Yes, this is true... I take responsibility for this; I guess I have
> been waiting to see how our trial run goes before updating the website
> and putting references to the new resources. I will try to make these
> changes by the end of the week and will decide on an initial strategy
> to use for policy which can be refined as we go along.
>> I understand the benefits of tickets (maintianing lists of bugs, etc.,)
>> but all my VXL work is currently done via email. Can I get it to email
>> me about new tickets? Is there some integrated RSS reader for
>> Thunderbird that will give me an acceptable illusion of emails.
> The main problem is that we do not have access to complete
> customization of trac as it is a hosted sourceforge app.
> TracNotifications was enabled about 1-2 weeks ago by the sourceforge
> staff... I did a check and it does send out email, but it seems it is
> not sending email to the sourceforge account automatically when the
> username is used (i.e., if the ticket is assigned to miguelfv it
> doesn't send it to miguelfv@...). However, if you
> add yourself to the CC it does send out notifications.
> I will try to fiddle with this some more, but I'm not thrilled about
> having my email visible for spam harvesters...
> RSS works pretty well. On the bottom of every page there are links to
> rss feeds that you can enroll to. The trick is to find the global
> place of the information that you want to find. For example, if you go
> to the [view tickets] tab there are several reports you can choose
> from like [My Tickets]. You can also track the timeline, wiki pages,
> So far, what I tend to do is that I am subscribed to the timeline
> (with only the ticket checkbox checked), so that I can keep up with
> every new,closed,reopened ticket. If a ticket is mine or I am
> interested in it, then I subscribe to that particular ticket as well
> so that I receive notifications of every update to the ticket. All of
> this is very easily done with mozilla thunderbird or your favorite
> news reader app.
>> What am I actually supposed to do about bug reports and feature requests?
>> For example https://sourceforge.net/apps/trac/vxl/ticket/39 is a request
>> for a canny implementation in vil. This is an entirely reasonable
>> feature-request, that comes to me as the lead maintainer of vil. Yet I
>> have no intention of doing any work on it, but will happily help/advise
>> someone else who wants to contribute some well designed and tested code.
>> Should I leave requests like this pending indefinitely? - in which case
>> the tracker will fill up with similar nice-to-have-but-not-my-problem
>> issues. Should I clear it with a wontfix, or similar?
> The lead maintainer of a module is automatically assigned a ticket so
> that he can manage it properly. This means that he should decide the
> importance/urgency of the ticket, if it has a patch attached maybe it
> can be applied with no problems, etc. However, in the case of feature
> requests that you/we don't have time to implement, the lead maintainer
> should just unassign the ticket from himself after doing some minimal
> management, such as making sure it is tagged as a feature_request and
> it is assigned to the correct component, etc.
> This is because if it is assigned to someone, it gives the impression
> that someone is working on it... As far as filling up the tracker, I
> don't see a problem with it because the reports help filter out what
> you're looking for and someone might just pick it up someday :)
> Actually, this is where the tracker is very useful in contrast to
> e-mail... these things can be archived and retrieved easily as opposed
> to finding that thread about some feature in the mailing list.
> Of course, there are things that we can do (which I will try to
> outline in the info I put up) such as making users aware that this is
> a volunteered based community so we appreciate patches as opposed to
> just a report of a feature request. Also, duplicate reports should not
> be submitted (another reason to have the lead maintainer do some
> minimal management).
>> Finally I would like to make a proposal.
>> Until all the webpages and vxl-list-policy have been updated to suggest
>> appropriate behaviour, perhaps it is unfair to ask people to use the
> As mentioned above, I'll flesh something out by the end of the week...
> However, we will need to adjust it to the communities need, so that
> trac helps us improve our workflow as opposed to getting in the way.
> Hope this helps.
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> Vxl-maintainers mailing list