Scheduled/Draft Posts

Now that we've finished the first draft of site search, our next major project is going to be scheduled/draft posts, which are two separate concepts that we've been bundling together since it'll likely be easiest to do them together:

* The ability to save entries midway through writing them, on our servers, as a draft that you can come back to later from any computer;

* The ability to write an entry and schedule it for posting sometime in the future, either once ("post this next Wednesday at 9PM") or recurring ("post this every Monday at noon").

We have specs for both scheduled posts and draft posts in Bugzilla, but we also wanted to throw it open to the crowd for discussion in case anyone has some awesome ideas we haven't thought of:

* What would you want to see a system like this do?

* What would make you want to use it, and what would be the "killer app" for you?

Update Page

Part of this project is also going to involve redesigning the Update page.

We want to make it possible for you to access your scheduled and draft posts at the time of update, in order to work with them, as well as giving us room to add more options in the future. The existing page doesn't have a lot of leeway for us to add new things, and some of the things we've added since we branched from LiveJournal don't integrate very well.

The resulting Update page after the redesign is likely going to be considerably different than what it is right now. (For instance, I'm tentatively thinking about folding in some of the functions of the Edit Journal Entries page, turning the update page into more of a dashboard, where you can access all of your recent posts -- published and unpublished -- along with your publishing schedule, and then edit or reschedule them, or create a new post -- but that's just a very vague idea.) There's also a lot of things we can do for that page, accessibility-wise, to make it easier for people who use assisitive technology.

We don't want to make things worse from a usability standpoint, though, since writing entries is one of the core functions of the site! Mark has done some statistics about which options are most frequently used while posting, which we'll be taking into account, but I also wanted to ask for thoughts:

* The four most-used options at the time of posting, from our data, are: icon, mood, tags, and crossposting. If you consider something else (other than those four) absolutely critical to how you use the update page, what is it?

* What's one major thing you always wanted to change about the current Update page, and why?

* What are the things you've always liked about the current Update page, and why?

We'll use your opinions to come up with the next iteration of the Update page, which will probably go through several revisions until we come up with something that we (and you!) are satisfied with.
So, now that [staff profile] mark is working for Dreamwidth fulltime, we're going to be working on many of the "big" projects that we want to do. One of them is a DW-native form of photo/image hosting that will let people upload images, maintain image galleries, quickly post images, etc, etc.

It'll be a while before we can have something released, but we're starting the design-and-spec process now! We have some ideas of our own about how it should work and what features it should contain, but we're turning to you guys right now at the very start, before we say anything about how we want things to work, to get your input and ideas without influencing them.

What features do you guys look for in photo/image hosting? What would you consider a "must have"? What would you consider to be nice but not necessary? What would be your "killer app" for image hosting -- the thing that would make you go "oh wow!" a lot and recommend it to all your friends?

Don't think about whether something's possible or not -- we want to hear your pie-in-the-sky ideas, your craziest thoughts, as well as your list of what features you'd absolutely require before you started to use it.
It's been a while since the last one, so [staff profile] denise suggested that we do another Dreamwidth-the-Business Q&A session.

But first, some data. One of the things that we promised when we started this site - and still do! - is that we will be open with the details of how the business is run, how it's doing, where your money is going, etc. Given that, here's the breakdown of our first few months of operations (discounting May):

June: $7,500 income
July: $5,000 income
August (thus far): $2,500 income

This is pretty much what we expected. More people buying accounts towards the beginning of the site, tapering off as we come up towards the various renewal periods. We're comfortable with these numbers and trends so far.

Our current monthly expenses come to about $6,000. This breaks down roughly 50/50 into "server costs" ($3k/month) and "people costs" ($3k/month). We are presently paying a few people as contractors to do time-sensitive and business-critical work for us. (Systems administrators, ToS enforcement, and some development time.)

We are not, currently, paying any salary to Denise or myself. (Which is one thing we really hope to fix...but stay tuned for today's news post.)


Dreamwidth is running slightly in the red, but has enough money in the bank to keep the site running for several years at the current run rate. We have a few things in the pipeline which we hope will allow for us to increase the attractiveness of the site to paying customers (features) as well as give us more sources of revenue (credits, virtual gifts, etc).

There will be more data about our next-6-months plan in the upcoming news post. But for now, if you have any particular questions about the business, things you want clarified, or anything, please comment. Denise and I will be happy to answer!
qilin: A qilin roof ornament silhouetted against the sky, overlaid with qilin in Chinese characters. (Default)
([personal profile] qilin Jul. 27th, 2009 09:24 pm)


We have some really difficult topics to work through today, so I hope you bear with me, and discuss the issues that concern you in the comments.

On to the topics! )
qilin: A qilin roof ornament silhouetted against the sky, overlaid with qilin in Chinese characters. (Default)
([personal profile] qilin Jun. 30th, 2009 12:38 pm)


As promised in [site community profile] dw_news, this is a summary of the activities of the TOS team since launch. The TOS team currently consists of the site owners [staff profile] denise and [staff profile] mark, who set the policies, and [personal profile] jennifer and [personal profile] qilin, who co-manage TOS support. I've tried to strike a balance here between transparency and privacy; I hope it gives you a good idea of what's going on without violating anyone's confidence.

On to business! )


ETA1: The RSS feed was found to not link to changesets correctly; switched the link in this article to the Atom feed. Also clarified wording on the topic stripping ads from feeds.

ETA2: From the suggestions of [personal profile] azurelunatic, there now exists [syndicated profile] dw_tos_feed!
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.)
So, I've already made a few posts about our business plans and questions that we're hearing often, but I also figured I'd throw open an "open Q&A" post, to see what it is that I'm missing.

Are there any questions you have about the business aspects of Dreamwidth Studios, LLC (the company that owns and operates Are there any business-specific questions you'd like to see me tl;dr on about? Any statistics you'd like to see? Any numbers you'd like to know about?

We do plan on running this service as transparently as possible and telling you guys as much as you'd like to know, so speak up now so we can get started early. (I'll do a roundup post after the weekend with answers.)
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
([staff profile] denise Apr. 11th, 2009 02:25 am)
Because we are committed to maintaining a stable, reliable service without ever accepting third-party advertising, we rely on subscription fees from our users to help us meet our operating costs. In exchange for those subscription fees, we offer additional or expanded services and features to our paid users as a way of saying thank-you for subsidizing the service for everyone else. We also reserve the features that cost us money to offer, or that cause significant database or webserver load, for users who have purchased paid accounts.

All of our assumptions, spreadsheets, cost projections, and business plans were done at a 5% paid account rate: each paid account will subsidize 19 free accounts. This applies whether the paid account is for a month or a year. Every payment someone makes will help pay for our servers, our bandwidth, necessary professional services, and the salaries and contractor payments we will be making to those who help develop and run the site.

We project that it will cost us approximately $1.40 a year to support each active user.

Features are reserved for paid contributors for two reasons:
  1. Because offering the feature costs us more than a few cents per user per year;
  2. As a way of saying "thank you" to users who have chosen to support the site, and other users, financially.

This means that some features are reserved for paid users because they're expensive, and some features are reserved for paid users because they're popular. (Sometimes, it's both.) For features that have limits, we offer higher limits to those who choose the Premium Paid account level. This reflects the fact that offering higher levels of these features costs us more money.

As we create new features, we plan on doing it two ways. Some features will be entirely reserved for paid users. Some features will be available to everyone, but significantly enhanced for paid users. We want to strike the right balance between rewarding people who've chosen to subsidize the service for everyone else, and making the service useful and functional for members of all levels.

We know that we likely won't get it completely right on the first try, especially since many of the paid user features on aren't available to us to use (either because LiveJournal's implementation of the feature isn't Open Source, because offering that feature would require expensive external partnerships, or because we don't think the implementation LiveJournal chose was the best way of doing it). During our first year of operations, we will constantly examine the paid user features and see what we can add.

Here's a list of the paid user features that will be present at open beta launch (along with why they're a paid user feature). Right now, you can see the Account Levels wiki page; we'll move that information onto the site before we launch to open beta, as we get our payment system finished.
Paid user features at launch )

There are two things that LiveJournal reserves for paid users that we allow every personal account (ie, not OpenID accounts) to do, because we think they're such critical and useful functions of the site that all users should be able to do them. Those things are:
Things available to all users )

In our first year of operations, we'll be adding a number of features that are either paid-user-specific, or are significantly enhanced for paid users. Right now, the plan includes any or all of the following:
Coming Soon! )
So, once we get into open beta, what will our development priorities be?

In general, we're trying to distribute our efforts evenly across three areas: 1/3 to bugfixes, 1/3 to general cleanup tasks (making the backend code better, more modern, and more reliable; making the frontend more usable and useful), and 1/3 new feature development.

Releases will most likely be on a biweekly basis, and we'll release code to a staging/beta environment before releasing it to the userbase in general. At any given time, we'll have three branches running:

* The development branch, into which we will commit that fortnight's changes. Every two weeks, we'll move that into:
* The staging branch, which is a snapshot of the previous two weeks' development efforts, for testing purposes, after which it will become:
* The production branch, which is what will be running on

Our full bug list can be found at Bugzilla. This entry will serve as an overview of what our major milestones will look like.

Open Beta )
Site Launch )
Third Quarter, 2009 )
Fourth Quarter, 2009 )

Our unmilestoned bugs are ones that are either minor enough that we'll take a patch for them whenever someone gets around to them, or ones that are major enough that we've prioritized them for 2010 or beyond. We'll always try to prioritize things at least six months in advance, so people can see what we're planning on putting the majority of our development effort into.

At the end of 2009, we'll also poll our users for your most wanted features, so we can set our priorities for 2010 accordingly. (We did the priorities for 2009 based on listening to comments on the dw-discuss mailing list, as well as from our experience elsewhere.)
Welcome to [site community profile] dw_biz, where we'll make regular posts about the business operations of Dreamwidth Studios, LLC, the company that runs We'll use this to talk about the reasoning behind our business decisions, tell you about what we're doing, answer your questions about our operations, and generally keep you informed.

Posting to [site community profile] dw_biz will be limited to Dreamwidth's owners and staff, but anyone can subscribe to the community and make comments to posts.

For our inaugural post, I figured I'd provide answers to some of the common questions we've been hearing. (Many of these questions and answers come from the Business FAQs list that we kept on the Wiki up until now, but I wanted to move them into [site community profile] dw_biz for posterity's sake.)

Operating Structure )
Account Types and Costs )
Feature Design )
Site Content )
Overall Site Questions )