Alicornutopia

I've been going with - because to me _ looks ugly and space looks nonstandard. I would prefer it if people all decided to do one thing (which seems possibly unlikely). I don't think forcefully restricting it is a good idea, because it goes against the whole author freedom thing.

Edit: For that matter, capital letters are annoying in screennames too (though rare).

My aesthetic sense objects to a Capitalized-Name but not an UPPERCASE-NAME, which is an example of why I don't think actual restrictions are a great idea. (I also in general think - is a better character than _ but _ is more Traditionally Usernamey.)

If we can come to moderate agreement on this, could we have text on the edit form with style recommendations?

I wouldn't strongly object to that, I don't think, and if other people think it's a good idea I'd be happy to add it.

I feel like we're not going to come to a good consensus on this.

Personally, I use "all lower case, separated with -" for my character screennames and "case structure may vary, separated with space" for my setting screennames. So the taieli monument is "ametira iltaiel" and Terraria is "Dig! Fight! Build!". This gives me a nice distinction between the two categories of thing. (I used to separate with _ to match Dreamwidth, but then most of my screennames didn't match Dreamwidth anyway so I switched over. Also note that Dreamwidth screennames appear in the journal URL with -.)

With respect to this further conversation about author locking, it seems like the authors should be set in the post itself, as with the privacy settings (with an option to have it "open to all" or "lock to current authors", probably).

What I'm not sure about is how much coauthors should be able to change. If they can kick out other coauthors, they presumably shouldn't be able to kick out the post creator, but then if the post creator wants to abandon a post or only wanted to be present for the introduction, this could be inconvenient. It also has the risk of coauthors kicking out other coauthors maliciously, especially if the thread starts off being "open to all" and then someone joins it specifically to lock out everyone else.

That won't happen

By which i mean, open to all threads are very rare, we're a small community, no one here is going to do that so it's strictly a risk with someone else joining and griefing and in the worst case you admin types can kick the person out and restore the post.

For the general case i think no one should be able to kick post creator but they should be able to leave and join at will. But i think this is all overthinking it.

It probably is overthinking it. Proposal: a multi-select for coauthors, editable by all coauthors in the "edit a post" menu near the privacy list, and a button (either there or in the post dropdown) for the main author to leave the thread manually?

I favour this proposal

The one thing I see an issue with is – if tags owed functions based on the list of authors, and so someone wants to remove a post from their tags owed by removing themself as an author, then the post will not list them as an author even if they made a substantial contribution.

I could separate these two features, but I'm not sure how to implement it.

• Suggestion 1: the list of authors shown in post lists displays only people who have replied to the post, and the list in the 'edit post' thing controls who can reply and who has it on their tags owed.
• Suggestion 2: I could just implement the "hide from tags owed" thing when I get around to implementing this feature. Then you can hide people from the authors list even if they've contributed replies (and simultaneously kick them from the post), and separately people can remove it from their tags owed page.

I favor suggestion 2 here. The previous proposal for UI still stands, with something else (in the post dropdown? on the tags owed page?) to let people hide posts from tags owed.

Edit: Okay looking back on this I feel like suggestion 2 is clearly superior and also what people have been asking for almost all along, instead of a vague suggestion that might implement a desired feature, so if there's no feedback I will assume that's preferable. I don't know when I'll get around to this but it shouldn't be too hard.

At some point I expect we should change from an ajar beta to something more open, so we might want to consider briefing potential.

What if certain functions were thread-owner-only but the creator could make a coauthor the owner? That’s relatively common for permission models.