Change History (8)

Trac regulars are, I take it, all subscribed to tickets by email, so the added benefit of this would be to pseudo-assign tickets to bug gardners -- in that whoever adds keywords, changes the ticket's component, etc. will then get follow-ups by email.

I think a better approach would be to have a tag that the documentation clearly says should be used only by the "trusted" few, who should be explicitly named or given titles. Then when the common folk use it, you could just gently remind them not to and change it back. The "commit" tag used to be like that implicitly, perhaps also "bg" from years ago.

Taking away actual permissions to edit tickets fixes a phantom problem, or at least one I haven't observed (and I try to read every trac post): rampant fights over ticket-classification. Sure, occasionally someone expresses displeasure that his or her ticket isn't considered the highest priority, but the very few exceptions proves that the general rule is working fine. Fighting over tickets isn't a big problem.

Most people recognize that a big problem is that there's a bottleneck of sorts in getting tickets committed or closed, as discussed in IRC yesterday. And one of the goals of the discussion was to figure out how to improve the community. So if we want to expand the community and lessen the work load of the commit devs, it seems counterintuitive to take away permissions and restrict people's access.

We have newbies who occasionally do a poor job of classifying tickets, and we have a few people who think their pet patch must be included asap. But that should imply that the non-newbies provide better guidance and examples, not that we lock down the ticketing system. Insert your favorite analogy: we teach children not to touch the stove rather than lock them in their room, e.g.

We need dedicated volunteers to help close tickets, to make tags more meaningful and helpful to the commit devs, etc. People can do that even if they haven't won "trusted" status yet. In fact, their doing it will help them win that status as well as get them excited about being involved in the community. If they do it wrong the first few times, guidance from others will demonstrate to them and to observers a better way, and community overall will improve.

We may have understood yesterday's discussions differently (or maybe you left before I did). But it seemed to me that keywords, severity and milestones had not become ignored to a large extent already. Reports 9 and 27 suggest the same:

We may have understood yesterday's discussions differently (or maybe you left before I did). But it seemed to me that keywords, severity and milestones had not become ignored to a large extent already. Reports 9 and 27 suggest the same:

"Had not" or "had" become ignored?

But I don't understand your point. The fact that we have and can create custom reports suggests that we don't need to reduce users' trac permissions: the commit devs can look at stuff that's just in a particular report.

I think it would be very beneficial (for everyone, and in particular the committers), if the reports returned meaningful results, rather than garbage.

I agree with the end goal, but I think in the long run we will best reduce garbage by handing out more brooms and teaching people how to use them, not taking away garbage cans.

You know how it is: sometimes there are long stretches when work obligations keep one from contributing much to WP. Even several of the commit devs have gone for weeks without any committing. If we take away the keywords, etc., from ordinary users, the "trusted" few will end up overwhelmed (just like the commit devs now), and instead of poorly-tagged tickets stagnating we'll have un-tagged tickets stagnating. Contributors will still feel like their tickets are being ignored, and they will feel even more impotent because they can't do anything to draw attention to their tickets.

Instead, we should expand users' involvement. Reserve a keyword or two for the "trusted" to use, but encourage all toward constructive contributions.