account: split RT queues/mailing lists into own sections

[fawaf]

+1 to sections

[kpengboy]

Looks like more people are in favor of merging this, so I'll do that. We can further divide up the misc section in future changesets.

[chriskuehl]

? you didn't even answer my question.

what problem are you are trying to solve here?

[kpengboy]

Making the list more organized, so:

• It's easier to tell why a name was added to the list
• It's easier to tell if an RT queue or mailing list hasn't been reserved already

To the second point, in the commit right after this one, I caught several RT queues and mailing lists that we forgot to reserve; it was much easier to do that because the names were all in one place.

[matthew-mcallister]

@chriskuehl I think the principle "benefit" is documenting why a username was added to the list. This is of potential historical interest and may prevent idle head-scratching. Also, it would be very helpful if we ever decide to prune the list instead of reserving names forever (not that we're likely to do this). So no technical advantages, but there's also no technical advantage in having them alphabetized either, and I doubt it will ever become hard to maintain separate sections.

EDIT: @kpengboy makes a good point that it's easier to notice when we forgot to add a username.

[chriskuehl]

There is a slight technical advantage to not doing this in that it's easier to add new names, but @kpengboy's identified problem of it being harder to see which mailing lists are reserved sounds more important to solve. That's why I asked the question.

Seriously, if the "why" is not blatantly clear from looking at a diff, I'd encourage putting half a sentence into the PR description. It helps a lot to understand where you're coming from.

[chriskuehl]

(personally what I would've recommended is making separate sets, e.g. MAILING_LISTS = {...}, SYSTEM_USERS = {...} and then at the end doing RESERVED_USERNAMES = MAILING_LISTS | SYSTEM_USERS | ...whatever else...; then you get the benefit not only of separating things out for human readers of the code, but you can also use these constants for other purposes)

[kpengboy]

@chriskuehl sure, I guess I could've done that.

As for your other suggestion, sounds interesting, we can consider it for a future PR.