I figure its best to add this as a ticket for Rob to make a decision on, since http://chatlogs.musicbrainz.org/musicbrainz-devel/2010/2010-03/2010-03-04.html#T20-48-24-483315 was going in circles.

Regarding proposals, apart from anything that would entail 'real' server changes, we have two that are far more common:

• Add/modify/remove something in the AR table (Relationship Editor tasks)
• (re)transclude some wiki page(s) (Transclusion Editor tasks)

Neither is a style council task. Sending an email to the style list and assuming some RE/TE will see it and take action didn't work when it was informally tried, nor is that within the described purposes of that list - "discussion about general style issues and the style guidelines". This isn't about guideline changes, this is only about what happens after the guideline/AR/whatever is changed, for any proposal where something entirely new to the server isn't involved.

The proposal process, as we'd laid it out a year+ ago, said that a trac ticket should be created for any RFC in progress, with that ticket eventually then (when the associated RFV passed) being updated to describe what RE/TE/dev task(s) needed to then be done. http://wiki.musicbrainz.org/Proposals is handling most of that now, but tracking post-RFV AR table edits or transclusion tasks is beyond the scope of that table.

These are by definition "MB server tasks". So enter JIRA - we have a "task" type of ticket, which would seem to map 1:1 to these, so they can be tracked and so we can ensure they actually ever get done. These are applicable now, however, and not just a part of NGS development; hence my request for a "mason" (or "now", something like that) option so there's actually the right option to assign to these.

It just seems wrong to me that such tasks would simply be assumed to happen "somehow". It's been tried before. We ended up with only some RFV's actually ever getting implemented; one AR passed RFV but two years later had mostly been forgotten about because it was just assumed that, after the RFV passed, some RE would implement it - and no RE ever did. It only actually happened because I emailed several REs until I found one who still was active and willing to take a few minutes to add it to the AR table.

We need some tracking mechanism for this type of task; assuming it will just happen "somehow" is the other half of why the old proposals process broke - even when someone did follow the process, after that process ended, there was no clear mechanism defined for how the resulting tasks would be tracked to make sure they weren't forgotten.

nikki's been good about making AR table modifications when I've asked, but how is an AR table mod (I create task ticket with the info, assign to nikki, nikki/some other RE accepts and makes the changes, then closes ticket) different from any other server dev task? Same for transcluded pages in need of retransclusion; there's not any mechanism atm for marking a wikipage as in need of re-transclusion; it ought not to be needed that I or anyone else be emailing/IRCing (in private, pretty much by definition) transclusion editors for that type of stuff to happen, when a simple task ticket does it (in public) and is harder to misfile and accidentally forget.

We have all the systems to handle this. I honestly have no idea why they wouldn't be tracked in jira, just as they have been in trac for several years (if only inconsistently). Emailed requests for such actions to the style list, private IRC PMs/emails, etc, have proven to work only very inconsistently, as well as, to me, seeming counter to the MB social contract ("The development process will be open to the public by using public mailing lists, meetings open to interested parties, and open IRC channels." and so forth) in a way that tickets in JIRA or Track (which makes that aspect of MB dev publicly accessible) aren't.

I know this is long, and I apologize, but I've frequently ended up being the one who's chasing down the RE or TE get get something done post-RFV; I don't mind doing it, but I'd prefer a real system like jira for doing it, when the alternative is just me pestering the same couple of REs/TEs by email/IRC until some task(s) eventually get done; without that followup, the proposal process itself suffers, as people see proposals go nowhere even if they are discussed and passed.