So, one of the things we want to do -- and it's a project that has gotten some developer interest lately -- is make it so that you can associate/link accounts together, so (for instance) you can switch to commenting or posting as your alternate/secondary/fic/RP/whatever journal more easily than logging out and logging back in. We've done some work to spec the problem, but I figured it would be time to toss it out to you guys here and see what other things we've forgotten to think of and what use cases we don't know about yet!

More discussion on the problem can be found at Bug 76. Here are two of the documents that have been written to try to "spec out" the project. Please read them over if you have a chance, and give your feedback.

Draft Spec, written by cesy )

Further considerations, written by tyggerjai )

So! What thoughts does this inspire in you?
So, one of the very first things that I put on my "things I want to do with Dreamwidth" list, way back in the middle of 2008 when we were making lists of "things we always wanted to do", was: redo the "memories" feature. One of my first decisions when thinking about the project was that I wanted to gut the existing system and start over again, since in the years since memories were first created there have been a lot of advancements in social bookmarking: sites such as del.icio.us have set the bar high, and there's no reason to redo the system if it's not going to offer something (or multiple somethings) that Delicious can't offer.

So, I wrote a basic spec that was chock-full of things I thought would be really awesome, and stuck it in Bugzilla, and put it on the list of "things we will get to when we get past the initial projects we want to add", and time passed. Then, a few weeks ago, [personal profile] yvi came to me and said she was looking for a complex summer project to really dig her teeth into. Since the memories-intto-bookmarks project is one I've been really looking forward to, it was the first idea I threw at her, and she thought it was awesome, too.

This is [personal profile] yvi's working version of the spec, based on the version I wrote a while back, and it is now time for everyone to weigh in on what they think! Please read this spec and give it careful consideration, then let us know your thoughts.

Turning you over to [personal profile] yvi now:

Social bookmarking feature spec )
A few weeks ago, I solicited thoughts on an official-community commenting policy, and then (as one does) promptly got eaten by the process of getting the site into open beta. We got a lot of really useful and helpful feedback and commentary on the initial round of brainstorming, so here's round two: a summary of all the issues raised in the commentary period that I feel should be incorporated into the final version. I'm posting so that if any feedback you left on the original RFC didn't get mentioned here, and you feel it should be incorporated into the final version, you can point me to your comment again. (Or, if you want to add something else to the discussion, you can bring it up here.)

The reason I didn't incorporate everything is because I felt a bunch of comments addressed broader issues or meta-issues -- things like "identify who's moderating each individual community" and "should we have different policies for focused posts vs. generalized announcement posts", all the way up to "we need a better way of providing feedback than comments". Most of them are really good process suggestions, and I'll definitely be taking them into account as we shape our communications, but for this specific task I'm trying to focus in on the issues that will help me write up a succinct policy that will cover 99% of what we need to cover in roughly three paragraphs or less. (Without tending to my usual verbosity.)

Round three will be a proposed wording of actual policy that y'all can proceed to pick apart, find all the holes in, jump up and down on, tear into little tiny shreds, and rebuild it bigger, better, stronger, faster.

The major issues that were raised in the commentary period:

  • How do we make it clear that we welcome dissent and disagreement, and are completely open to feedback of all kinds (positive or negative), without watching the comments degenerate into either people (on either side of an issue) attacking each other or an endless string of non-productive commentary or disruptive behavior?

  • How, in fact, do we define 'productive' commentary? How do we define 'disruptive' behavior?

  • 'Be polite' or 'be civil' is impossible to define in such a way that everyone will understand what you mean. One person's civility is another person's utter rudeness.

  • We need to come up with some kind of way to identify what our definitions of all of the above are, in the context of DW official journals, without giving offense or making angry people angrier. Examples are good.

  • We also need to make it clear that "stay on topic" doesn't prevent people from asking questions about DW that might not relate to the exact post. (Otherwise known as: OMG my journal is broken, I don't know where to ask about it!)

  • Who gets to say that something violates these rules? How do we keep it from turning into people trying to moderate each other's behavior? (Otherwise known as: sometimes, with friends like these...) We don't want people who are really loyal to DW shouting other people down.

  • Moderating with too heavy a hand will lead to resentment and backlash; moderating with too light a hand will lead to wank, trolls, "First!", and "cry moar, emo kid".


Is there anything else that you feel is important or relevant to the task of writing up a broadly-focused commenting policy for official Dreamwidth communities?
(RFC: "Request for comment" for peer review in Internet terms, and how we'll be developing our policies. We'll post things to [site community profile] dw_biz tagged "request for comment", leave the commenting open for a period, and then integrate your comments and feedback into whatever policy we're developing. Most policies will go through several rounds of RFC.)

So, part of what I want to do is make sure that we have a very clear commenting policy for Dreamwidth "official journals" (anything that starts with dw_*) and that we enforce it from the beginning, in order to be consistent in our moderation. We'd like for our official journals to be places where people can feel comfortable bringing issues to our attention, providing feedback, and asking questions, without having to worry that they'll be attacked or derided by someone else. At the same time, we want to be as clear as possible about what we will and won't moderate, so people who are commenting know what we expect of them.

We want the comments to our official journals to be useful, on-topic, and relevant, whether ultimately positive or negative towards the project. In particular, we want to make it very clear that disagreeing with other people, raising objections, criticizing [staff profile] mark and me, or pointing out problems is perfectly okay, while at the same time making it clear that ad hominem attacks, treating others with hostility or malice, telling other people that their comments aren't productive/contributing to the discussion, telling others things like "cry moar", and comments that derail the discussion without contributing anything of substance (so, like, pages and pages of cat macros) will be screened and may result in the commenter being banned.

What sort of things do you guys think a commenting policy like that would require to be spelled out, and what can be taken as understood? I want to avoid saying things like "treat others with civility", because "civility" is a term that varies from culture to culture, but I also want to get this sort of commenting policy into place as early as possible, while our "early adopters" are people who come to the project with good faith and a desire to build a productive community, so that things are ingrained in the culture from moment one.

I have a vision about the sort of thing I'd like for the policy to contain, but I'd like to get feedback and suggestions from you guys first, before I attempt a draft of it. (Once I do, I'll post it here for people to go over and suggest improvements.)
.