AO3 News

The Archive of Our Own is growing rapidly! We now have over 145,000 registered users, and about 275,000 unique visitors a day. All these visitors rack up roughly 4.3 million pageviews a day (that's almost 3,000 a minute on average). It cost more than US$52,000 to keep the Archive up and running in 2012. Our costs will only increase as the Archive continues to grow, and we anticipate spending at least US$70,000 in 2013.

The Archive is funded entirely by donations to the Organization for Transformative Works. As part of the OTW's membership drive, we'd like to share some details of what we have to pay for and how much it all costs.


The Archive of Our Own is hosted entirely on servers which are owned by the Organization for Transformative Works. This is a key part of our mission: fanworks often disappear from the internet because a site goes down without warning, or because a takedown notice is issued and site owners are unable or unwilling to resist it. By owning the servers, we ensure we're in a position to protect fanworks and keep them available.

Servers are a one-off cost, although over time they have to be replaced or added to. Over the lifetime of the Archive, we've spent US$58,099 in total on hardware. This was spread over several years:


When we launched the Archive in 2009, we started with two servers with upgraded RAM, which cost a total of US$8,165 (including shipping).


In 2011, we expanded our server family substantially, adding four more servers and a switch. The total cost for the new hardware was US$17,234.


By the end of 2012, the extremely rapid growth of the Archive meant that we needed to add more new servers. After some extensive research by our Systems team we settled on three new machines, at a cost of US$28,200. In the same year we upgraded our existing machines by adding some solid state discs — a cost of US$1,650 — and upgrading the RAM — this cost approximately US$2,200.

The size of the Archive codebase and the number of volunteer coders we have working on it meant that in 2012, we also needed to upgrade our testing and development environments. These are used to host web-based coding environments so that our volunteers don't require very high performance computers to code on, and a test environment where our testers can test the new code before it goes onto the live site. We were lucky enough to have these machines donated, so we didn't have to pay up front for them, but we bought a hardware-based firewall for these servers at a cost of US$670.

Our total cost for hardware was US$32,720.

Colocation and hosting costs

The servers themselves are only a small part of the cost of running the site. We also have to pay for them to be physically hosted in a colocation facility: we rent the space for them and pay for electricity, bandwidth, and the physical maintenance of the machines (so if we need to add a new disc, for example, our colocation hosts do it for us). We also pay for a managed firewall at one of our colocation hosts.

Our hosting costs are US$1,365 per month, which breaks down as follows:

Hosting costs: US$1,315 per month
Managed firewall: US$50 per month

Additional tech costs

In addition to paying for hardware and hosting, there are a few other ongoing costs in keeping the Archive up and running. We pay a licence for a product which enables us monitor activity on our servers and to identify performance problems. This cost us US$1,400 in 2012 for June-December and will cost an estimated US$3,500 in 2013. (The cost goes up as we add more machines.)

We pay for backups and image hosting (only used for icons and collection header images). This costs an average of US$65 per month. In 2012, we also paid US$835 for cloud hosting to do some enhanced testing of the Archive code, prior to launching our new tag filters.

We currently pay to use a hosted ticket system for our Support and Abuse teams, which is used to keep track of queries from users. This costs US$180 annually.

And the rest

The above costs don't include smaller sundries such as the cost of our volunteer chatrooms, mailing lists, or other volunteer tools. The Archive is a project of the Organization for Transformative Works, so these costs are rolled into the OTW's overall expenses and it's not really possible to break them out as individual Archive costs.

Finally, there's one big cost which isn't included above: volunteer time. The Archive is entirely designed, coded, tested, and run by volunteers, who give many hours of their time to develop the site, support users, wrangle tags, and manage the servers. Their work is priceless. <3

Support the Archive!

As you can see from the above, it costs a lot of money to keep the Archive up and running. These costs will increase in years to come as more users join the site, and we expand the types of things we host (multimedia hosting is still very much part of our plans). In the next year, we expect our expenses to grow by nearly 50 percent, to a minimum of US$70,000, and you can help get us there.

The Archive is entirely funded by donations to the Organization for Transformative Works: we don't run ads on the site or charge people to use it. If you enjoy using the Archive and have a little money to spare, please donate to the OTW to help keep us thriving! A donation of US$10 confers membership in the OTW and the right to vote in organizational elections. At higher donation levels there are some awesome thank-you gifts to choose from, like our AO3 Kudos Water Bottle at the US$75 level.

Thank you to all our donors, past, present and future! We appreciate your support!


Known issues from our last deploy

Published: 2013-04-05 06:55:00 -0400

We're currently dealing with a few issues relating to our last deploy (Release 0.9.6), and we wanted to keep you in the loop on how we're handling them (and let you know about workarounds for a few problems):

Jumbled looking header

We launched a new design for our header, which should look like this. If it's looking jumbled, buttons are overlapping, or it otherwise looks broken, please refresh the page. If that doesn't help, you may need to clear your browser cache and then refresh again. If you're using a mobile browser on your phone or tablet, and clearing the cache alone doesn't help, try completely closing the app and opening it again.

Share box always open

Some users have reported that the 'Share' button that usually pops up a pre-formatted block of work information was replaced by the text it's supposed to hold. This severely messes up all work pages. It's due to a conflict with some userscripts people have installed in their browsers, which are interacting badly with a jQuery plugin we started using for our help boxes.

The quick and dirty way of solving this problem is to disable AO3-related userscripts.

The problem is caused by scripts which contain a @require line, which tells the script to grab a copy of jQuery from Google's servers to work with. That fresh copy then overrides our own Javascript stack, causing wonkiness. If you want to keep using the script, you (or the original creator of the script) need to edit it so it doesn't use this line. A helpful Tumblr user has written up instructions on how you can edit a userscript yourself, although this might not work in all browsers. Especially if you're using Chrome, try this little script change instead.

Subscription emails are missing information

We tested all possible Archive emails in various browsers and clients, which amounts to a lot of emails. In all this testing we missed that some information had vanished from some kinds of subscription notifications, for which we apologize.

Many, many users wrote into Support about this and commented on our Release Notes, and we are rolling out a very quick fix to bring back total chapter count, work summaries, and additional tags to all notifications.

New styling of emails

We launched new multipart emails which take advantage of HTML styling. This was to give us more control over the layout of emails, and to help provide a more consistent look. Our old mailer templates were mostly a mix of text and some HTML mark-up (for paragraph breaks, links, and some text styling) that did not actually declare itself properly to email clients. This raised our spam score, looked broken in some text-based email programs, and made it harder to add emails for new features, as there was no consistent style to base them on.

We assumed that users who preferred text-only emails would select this option in their email clients; however, it's become clear that this isn't meeting our users' needs, for various reasons, and lots of people would prefer to have a text-only option.

We're taken note of all the (strongly-felt!) responses to the new emails, and we're looking at solutions, including adding a user preference for plain text emails. We need some time for our coders to look at the issue and figure out the best way forward: when we've been able to do this we'll update users on what we are planning to do and when we will do it. Please rest assured we are taking user feedback very seriously; we appreciate your patience while we work on this.

Some users also raised specific concerns about the styling, notably the size of the font in certain email clients / devices. We'll also be looking to address these issues and tweaking the HTML emails themselves.


Release Notes for Release 0.9.6

Published: 2013-04-04 03:00:40 -0400

Welcome to Release 0.9.6: The Headering! Ariana, bingeling, ecuoln, Elz, Enigel, Nathan J Xaxson, Sarken, Scott, tuff_ghost and Tegan contributed code to this release, which was tested by our awesome testing team: Alison W, Ariana, Emilie K, Enigel, estirose, FishieMishie, Jenn Calaelen, Kylie, Lady Oscar, Matty, mumble, Sam J., Sarken, Scott S, and Tai.

NOTE: If you see a collection of buttons at the top of the screen rather than a thin bar with menu titles as in the screencaps in the header preview post, please try clearing your browser cache and reloading.

There are some instructions for clearing cache in various browsers here.


New header and footer and JavaScript, oh my!

This code deploy sees the release of our brand new header and footer! Back in February we gave you a sneak peek of our design, and we are now proud to give you the final product. Much love and thanks to Frontend Lead Sarken who was the lead architect for this redesign (and also made sure it works in all major site skins!), and many thanks to all those who spent hours poking and prodding it to make sure everything was working correctly in a wide selection of browsers and platforms. We have also cleaned up the footer so it matches the new header, and reorganized some of the links.

As we mentioned, a lot of work went into coding, testing, re-coding and re-testing the new dropdown menus, and we can confidently declare it usable with and without JavaScript enabled, no matter if you're using your mouse, keyboard, or touchscreen to navigate. It should also play nice with other assistive tech such as screenreaders. However, if you run into any issues on your particular device, please send in a report to Support and let us know! We will do our best to fix it.

In order for this header to be as accessible as possible, we were required to update to a new version of jQuery. (Also, it's just good practice to try and stay up to date.) Many thanks to everyone who helped regression-test features requiring JavaScript all across the site to make sure everything was still working as expected after the upgrade! Extra special thanks to Testing co-leads Jenn Calaelen and Lady Oscar for providing testers with a huge and beautiful spreadsheet of ALL the things to test and managing testing parties for our volunteers.

New notification emails!

With this release we also see the rollout of our brand new HTML and text-based emails! Frontend coder tuff_ghost was the driving force behind this massive undertaking, with beautiful HTML templates provided by summertea. All our email templates (comment notifications, subscription updates, challenge assignments, gift notifications, and many more) had to be rewritten to fit the new HTML design, and a plain text version had to be created for each email as well. Many thanks to tuff_ghost for all her hard work!

We now send out true multipart emails: users who for whatever reason cannot or do not wish to view HTML formatting in their emails will now be presented with a stripped down version of the message (as opposed to bits of visible HTML code or unclickable links). Delivering emails in this manner, and labeling them correctly in the email header, is another step towards keeping our emails from being flagged as spam by service providers.

New option to disable guest comments!

Finally, the last of our big features for this release is the ability for work creators to decide whether or not they will allow anonymous (logged out) comments on each work they post. The posting form has been adjusted accordingly and a new 'Privacy' subsection with two ticky boxes has been added: you can still restrict access to your work to logged-in users only, or you can choose to just disallow guest comments instead, while leaving the work open to the public.

New fixes to our automated tests!

For years now, we have been using something called Cucumber tests as a way to make sure our code isn't broken (without having to manually try out every possible feature on the site) whenever a new version of the site is finalized. However, every now and then we slip up in updating these tests or writing new tests to cover new features, leading to broken tests (the irony!) and making them much less useful than they could be.

While we're looking into ways to update and enhance our testing suite in general (e.g. with the RSpec framework), we needed to make sure our tests were useful again in the short term, and coder Scott has heroically stepped up to do just that. Many many thanks for all the hard work he's been putting in!

Known Issues

See our Known Issues page for current issues. This list is updated with each release, so please make sure to give it a glance before contacting Support - it might just offer you a temporary solution to your problem right away.

Release Details


  • Redesigned main navigation with drop-down menus and restructured footer area
  • Improved homepage to display the AO3 News more prominently, include a link back to the Archive's parent organization, and display all the OTW's twitter feeds for latest news
  • Ability to disable anonymous comments per work
  • Multipart emails (HTML/plain text) with uniform design across all Archive notifications
  • New About Us page

Bug fixes and backend enhancements

  • Previously it was not possible to edit works that were in closed collections. This has now been solved, and you can edit away!
  • When posting a new work, the date of the work was set to "2013-01-01" in some particular cases. This was a difficult to pin down bug involving the backdating option, and we hope it has been resolved now.
  • When you edited a chapter, then selected 'Preview', the preview page was rendering incorrectly. We have reworked this page, and previewing should now correctly display text changes.
  • Trying to look up an imported work using the original URL was throwing a 404 error. Additionally, the tool was causing problems when the 'www' part of an address was left off. Both have been fixed!
  • DeviantART imports were not working due to code changes on DeviantART's end. We have updated our import code to fix this.
  • There was a bug in our backend code that was affecting the archive importing tool, resulting in errors. The bug has been fixed.
  • Soundcloud has been added to our approved list of sites and can now be used when embedding media to your works on the Archive. 4shared has been removed.
  • Previously when works were deleted by the Abuse team, the email notification stated that the work was deleted at the request of the user. We have created a new mailer emphasising that the work was deleted for Abuse reasons and included a link to contact Abuse with any questions.
  • Co-authors were receiving emails leading them to believe that they had deleted a work, when in fact it was one of their fellow authors. The wording has been changed to avoid confusion.
  • When a user added a giftee to a work, and posted the work only after previewing, a gift email was not being generated. This has been resolved, and gift notification emails should go out using any workflow.
JavaScript and Frontend
  • The help boxes (visible, for instance, when you click on any of the blue questions marks across the site) were a combination of different patches and workarounds. The "lightbox" code to create these help pop-ups has been entirely rewritten for better performance and accessibility, also fixing a bug where keyboard navigation inside the box wasn't working in some browsers. Please note that optimization for the iPhone is still in the works.
  • The autocomplete dropdown (e.g. for adding tags to a work or using the wrangling interface) was not working on some browsers, most notably Opera. This has been resolved.
  • There were accessibility problems when attempting to remove tags from a work using screenreaders and keyboard navigation. The "X" that deletes a tag has now been tweaked slightly to allow keyboard access.
  • JavaScript tweaks have been added in some places to prevent the double submission of forms, e.g. when accidentally clicking a button twice. The 'Post' (or 'Update') button now changes into 'Please Wait...' once the form has been submitted.
  • On a bookmark index page, such as for a particular tag, opening multiple forms to bookmark separate works caused the character counter for notes to stop functioning. This has been fixed.
  • With JavaScript disabled, there were some non-functioning options when trying to access all pseuds by a user on that user's homepage. We have cleaned up this code to make it more accessible for those who choose not to use JS.
  • When viewing a user's fandoms, clicking the 'Expand full list' resulted in the addition of an ugly grey space between the top five and the rest. This has been cleaned up to display all fandoms as one continuous list.
  • The placement of our JavaScript code on a page was causing some performance issues. The JavaScript now loads after the main content, speeding up load times.
  • We have created touch icons for mobile devices, which should now show up when you bookmark any Archive address to your phone's screen.
Tag Wrangling
  • On Tag Wrangling pages, the ticky boxes for mass selection were in their own column, taking up valuable screen space. They have been moved to the column containing the tag names for more convenient selection.
  • When Tag Wranglers assigned an unsorted tag to a category (e.g. Relationship) and then searched for that tag, an error was occurring in Tag Search. This has been resolved.
  • When attempting to add synonym tags to a non-canonical tag, wranglers got an error message telling them that the tag wasn't canonical. The tag name is now a link to that tag, so wranglers can make it canonical if they wish.
  • Text on the Tag Wranglers' former landing page was edited and a couple important links were added.
  • The 'Unsorted Tags' wrangling page had no visible pagination links. They have now been added.
  • The Tag Wrangling menu has been re-worked to make the wranglers' workflow more efficient.
  • AO3 admins now have the ability to mass decline all requests for more invitations by registered users (like we decided to when we were battling server meltdowns last year), and notify the users by email with one button click.
  • Validation issues were making it impossible for admins to decline invitation requests by users by setting the number of invitations to zero. This has been fixed.
  • For ease of navigation, we have added Next/Previous links to the AO3 News posts.
  • At user requests, Quenya, Thermian, and tlhIngan-Hol were added to the list of languages a creator can mark their work as and to the list on the Languages page. Qapla'!
  • To make it easier for users to see the latest update about the state of the Archive during scheduled downtime, we added a feed of our @AO3_Status Twitter to our "The archive is down for maintenance" page.
  • We made some text changes to the page containing information about contributing to the AO3.
  • Safari on iPhones and iPads was getting stuck to anchored links (e.g. ?show_comments=true#comments) and after leaving kudos, not allowing users to scroll away anymore. This was a bug in iOS 5 that was taken care of in iOS 6, but should now also be fixed in older models.
  • Our automated tests were outdated in many places, leading to unhelpful results when running them. They have now been heroically fixed across the board.


Fandom is Love: OTW April Membership Drive

Published: 2013-04-03 11:56:53 -0400

Why do you participate in fandom?

For many of us, the answer to that question is love — love of a favorite TV show, video game, or band; love of fannish communities and the friends we make there; or love of the creative process involved in transforming canon to create something new. Fans put in long hours making and consuming fanworks, traveling to conventions, moderating communities, and chatting about their latest fannish passions — not out of obligation, not for pay, but because it brings us joy.

Like so many other fannish endeavors, the Organization for Transformative Works is a labor of love. We’re a nonprofit organization run entirely by fans, for fans, which relies on the generous support of donors and volunteers. During our membership drive from now through April 9, we invite you to become an OTW member by making a donation of US$10 or more. Your donation will help to sustain Fanlore, the Archive of Our Own, Transformative Works and Cultures, Open Doors, and our legal advocacy work. If you donate US$50 or more, you can opt to receive a thank-you gift to proudly show off your support.

Donations to OTW are tax deductible in the United States. If you have questions about donating, please visit our membership FAQ (located at the bottom of the donation page) or contact the Development & Membership committee.

The OTW and its projects depend on the support of fans like you. Be a part of this ongoing labor of love — please donate today.

Fandom Is Love: Organization for Transformative Works Membership Drive, April 3-9

<div style="text-align:center"><a href=""><img src="" alt="Fandom Is Love: Organization for Transformative Works Membership Drive, April 3-9" /></a></div>

Help share the love! Please repost this graphic by copying the code from the text box and pasting it into your blog or website.

Mirrored from an original post on the OTW blog. Find related news by viewing our tag cloud.


April Showers at the AO3 and Fanlore!

Published: 2013-04-01 11:46:58 -0400

Here at the OTW, preserving fannish history is a central part of our mission! We're proud to be able to offer fans a place to archive their works on the Archive of Our Own, and tell their own fannish histories on Fanlore. As of March 29, 2013, Fanlore has 24,423 articles which have undergone 439,529 edits, while the Archive of Our Own recently passed 143,000 users, and more than 640,100 works have been posted on the AO3, across over 11,600 fandoms!

We're really pleased and proud to see so much fannish representation. However, we know that there are many, many wonderful fanworks out in the world which haven't found their way to the AO3 - for example the classic television show M*A*S*H has only 264 works on the AO3 while Neverwhere by Neil Gaiman sits at 83. There are even more fannish stories left untold on Fanlore - we'd love to see the fannish activity over the Veronica Mars movie documented as it unfolds! Last year, we welcomed in lots more edits to Fanlore and works to the AO3 with our April Showers promotion. This year, we're hoping to do the same! This month, bring us fannish April showers by digging out those old zines, memories of past cons, archived personal webpages, tales of shipwars and fannish events, works on slowly-decaying archives, new works you've been putting off creating, and more! Upload your old (and new) works to the AO3 and tell your tales on Fanlore.

We'll be highlighting a different fandom for each day of the month on our Tumblr ao3org, to help jog your memories about fannish loves of the past and highlight some currently active fandom activity. When uploading to the AO3, you can tag your uploaded works April Showers 2013 - at the end of the month we'll round up all the works with this tag and post stats on how many were uploaded for each fandom. However, don't feel you have to stick to these fandoms - we hope people will reach into their personal fannish histories to preserve what's important to them!

We kick off today by hearing the people sing with the 2012 film version of Les Misérables. Bring your works beyond the barricade into the AO3 and share all of the dreams you dreamed on Fanlore!

Mirrored from an original post on the OTW blog. Find related news by viewing our tag cloud.


Volunteer Recruiting Update

Published: 2013-03-30 11:55:18 -0400

In April of last year, the Volunteers & Recruiting committee closed active recruiting of volunteers for the OTW and all of its projects. We did not make this decision lightly; we know the organization is entirely reliant on volunteers' generosity with their time. As we are now at a point where we hope to reopen recruiting in the near future, we wanted to take some time to explain the reasons for closing and the work that has been undertaken to improve our volunteer program in the interim in more detail.


Going into 2012, the organization had a system for recruiting that had worked very well in the past. Prospective volunteers completed a form that indicated their willingness to serve and areas of the organization that piqued their interest. The Volunteers & Recruiting committee would then work with committee chairs in an attempt to match those interests up with open places in the organization. As the organization grew in size and scope, so did the number of interested volunteers; the existing recruiting method became time consuming for Volunteers & Recruiting staff and chairs, and resulted in several instances of individuals volunteering for roles that were not accepting new volunteers at the time. These issues became increasingly apparent during the membership drive last April, when we saw a major influx of volunteer interest and had had to turn away skilled and interested potential volunteers due to a lack of available positions.

Volunteers & Recruiting closed external recruiting at that point, with a plan to revise the committee's internal procedures and then investigate and develop a new system of recruiting. Our goal in completing these tasks is to ensure the committee's procedures are up-to-date for each role while putting in place a recruiting system that provides more support to new volunteers while also ensuring chairs and leads can easily recruit for positions they need.

Induction Revision

The first large task for the committee was confirming with each committee chair and workgroup lead that the information on file regarding tool access for each staff, volunteer, liaison, and leadership role was up-to-date, so that new volunteers would immediately be able to access the tools they need to do their work. Based on this information, we created new comprehensive templates for all positions to guide committee staff through both the induction and removal process. As the organization currently has 25 committees and workgroups, this was no small task on the part of the committee and, in some cases, involved some additional research by chairs and leads regarding outside tools and procedures to be included in this process.

Technical Recruiting

To lessen the impact on technical projects and teams - specifically Systems and Accessibility, Design & Technology - a special Technical Recruiting form was opened in May to allow for limited recruiting of coders, testers, and sysadmins. This form and process were active until early September, when all recruiting was closed for a one-month period to transition to the new induction and removal templates and for Volunteers & Recruiting to ensure everything was up-to-date.

Chair Recruiting

Aside from the one-month full recruiting freeze in September, chairs and leads have retained the ability to recruit internally for staff and volunteers interested in joining additional teams and to privately recruit individuals for specific projects and roles to lessen the strain of the active external recruiting freeze. While these options have not been extensively used, they have helped some teams continue to function more effectively while the external recruiting process has been revised.

Volunteer Policies

During 2012, the committee continued to work on developing a Code of Conduct for organization personnel, a process originally started in 2011. The committee researched policies in place in other organizations, researched best practices in volunteer management, and worked with a volunteer consultant in developing a comprehensive Code. During this time, the Constructive Corrective Action Procedure, which outlines how to address violations of the Code or other issues with volunteer performance, was also drafted.

Both of these documents were sent out to all staff and volunteers for a two-week review period. During this time, personnel were able to ask questions about anything that seemed unclear in the documents or make suggestions regarding what was included in them. The committee made revisions based on this feedback and developed Frequently Asked Questions for both the CoC and the CCAP to address some of the questions asked during this time. The documents were sent out for another one-week review period before being sent to the Board of Directors for final approval. Board unanimously approved both documents on 2 November 2012.

The Code of Conduct will be made public on the OTW website as part of the new recruiting structure. This will give all prospective staff and volunteers a chance to review it before applying for an open role.

Position Descriptions and Training Plans

While researching best practices for volunteer programs, the committee developed the new volunteer and recruiting structure further by developing templates that can be used to create position descriptions and training plans for each role within the organization. Position descriptions not only help volunteers to understand their role, but they also outline responsibilities and desired qualifications, providing an up-front understanding of what is involved in the commitment. Training plans for each role also ensures that new volunteers are engaged and supported right away in learning about their new volunteer position as well as the internal processes of the OTW.

To provide support for all committees and workgroups in building the training plans, Volunteers & Recruiting developed interactive tutorials for organization-wide tools. These tutorials were tested by Volunteers & Recruiting staff as well as other staff and volunteers throughout the organization and will continue to be updated and expanded as needed. While these basic tutorials will provide a strong foundation in using the tools for new personnel, there are also plans to build more advanced tutorials for some of the tools in the future.

Interviewing and Selection Procedures

Under the old recruiting system, formal communication with prospective staff or volunteers between the time they expressed interest and their induction was often inconsistent as there was no clear organization-wide standard. In order to ensure that individuals stepping into roles have a better understanding of what is involved in their commitment and to aid chairs and leads in determining if individuals are best suited for a particular role, interviewing and selection guidelines have been developed by Volunteers & Recruiting. While the format and nature of the interview process may vary from committee to committee or role to role, all staff-level positions will include an interview step to allow for a dialogue and for both parties to determine if the role seems like the right fit.

(To clarify, the OTW differentiates between volunteers who serve on committees - "Staff" - and volunteers who serve on workgroups or in volunteer pools - "Volunteers". Staff roles typically involve a larger minimum time requirement and direct participation in committee work and decision-making.)

A New Application Process

With clear position descriptions, detailed training plans, and interview and selection procedures in place, the organization is ready to launch the new recruiting process. Unlike the original process of a single volunteer form with potential volunteers indicating their areas of interest, the new system will be targeted to specific positions. Essentially, the plan is as follows:

  1. Chair or lead notes a need to fulfill a specific role within their committee, workgroup, or volunteer pool
  2. Chair or lead notifies Volunteers & Recruiting and ensures that position description and training plan are up-to-date
  3. Volunteers & Recruiting posts the open position (including description of role and desired skills and abilities) on the volunteer landing page (with a two-week deadline in most cases)
  4. Individuals submit applications during the application period
  5. Volunteers & Recruiting closes the position and forwards submitted applications to the chair or lead
  6. Chair or lead contacts individuals who meet qualifications to discuss the position
  7. Chair or lead submits names of individual(s) selected for approval
  8. Volunteers & Recruiting contacts individuals not selected and refers to other open positions, if applicable
  9. Following approval, Volunteers & Recruiting contacts selected individual(s) and processes induction
  10. New staff/volunteer follows training plan and works with chair or lead to get started in new role

We anticipate some positions will be open on a more ongoing basis (volunteer pools like Tag Wranglers and Coder volunteers), while committee staff and workgroup volunteer roles will be open only when the groups are actively in need of additional personnel. This will allow prospective volunteers to be more effectively matched with open positions that fit their interests and skills while also streamlining the processes internally for Volunteers & Recruiting and for committee chairs and workgroup leads.

The number of positions open at a time will likely vary depending on the organization's needs at any given time. Through work with the Webmasters and Communications Committees, plans have been developed to market these opportunities as they come open. A sidebar on the OTW website homepage will show a random sampling of open positions at any given time. All position openings will also be broadcast through the organization's Twitter account and occasional roundups on the OTW blog.

So, What Now?

The work on the infrastructure of the new recruiting system is nearly complete. A number of committees and workgroups have prepared their position description, training plan, and selection documentation. And the Volunteers & Recruiting Committee is excited to begin actively recruiting new volunteers into the organization as soon as we can. We are completing our final preparations and plan to open up the first positions under this new model following the April Membership Drive, which runs April 3-9. A follow-up post will be made to the OTW blog when the first applications go up on the volunteering page.

If you have any questions, feel free to reach us through the Volunteers & Recruiting contact form.
Mirrored from an original post on the OTW blog. Find related news by viewing our tag cloud.


Archive Roadmap 2013

Published: 2013-03-27 11:03:20 -0400


The OTW Board is pleased to announce the newly updated Archive of Our Own Roadmap.

The Roadmap is a broad outline of planned improvements and changes to the AO3. It is maintained by the Accessibility, Design, & Technology committee with input from many OTW committees including Abuse, Internationalization & Outreach, Open Doors, Support, Systems, Tag Wranglers, and Translation. While such an involved cross-committee process takes time, we are happy that it includes input from so many committees because we believe that collaboration results in a high-quality document and (hopefully!) a shared understanding of how and why we do the things we do.

Updating the Roadmap is a huge task which involves:

  1. Talking to everyone to learn what is needed and wanted (which can be different for everyone but thankfully there is some common ground)
  2. Talking about priorities (because our wish list is way larger than our ability to grant wishes)
  3. Working out what we need to do to get from A to C (sometimes that means people get B first on the way to C even though B was low priority)

AD&T walked the Roadmap through multiple drafts (the first rough outline was created in August 2012) and worked with multiple versions of the Board (there were five new Board members in this period) to reach a final version. The Board would like to thank everyone who worked on this task for the energy (and patience!) given to make this possible. We really appreciate all the time the staff and volunteers put into this.


A Look Back

When we started working on the Archive in 2008, we drew up a roadmap of core functionality which included all the basic posting and searching features, the tagging system, collections, comments, and a translatable interface. The original roadmap was drafted with a view to completing this groundwork within a short timeframe, and producing a releasable package which other fans could download and use. However, once we started working on the goals defined by the roadmap, the landscape changed a little. Implementing these basic, interlocking features turned out to be more complex than we originally anticipated, and as a result, the whole timeframe stretched, leaving openings where new features crept in and new urgent needs arose.

We revised our Roadmap in 2010 to give users an outline of planned features and milestones which took into account the realities of developing the live site, and the demands of our userbase. While we've been following roughly that plan, you'll see from looking at it that we didn't stick to it exactly: we have to be flexible and modify the pace of work and the order of tasks based on user demand, the needs of the site, and the skills and interests of available coders. In general, the pace of development has been slower than we anticipated, although in some cases we have been able to bring forward features which were in high demand, while keeping up with increasing performance challenges as the userbase expanded.

Some of the features we planned to add after version 0.8 have already been implemented, including a "kudos" option which lets you quickly show that you liked someone's work without leaving a full comment, improvements to editing multiple works, a download function for individual works in different formats, and better HTML styling thanks to work skins. A public Feature Requests Board was established in the form of a third-party tool (see the related Internal Tools FAQ for more information).

In contrast, several features we planned for before the 0.9 release were pushed back. For example, we've made some excellent progress on multi-language support for the Archive interface, but realized that the latest version of Ruby on Rails (the framework the AO3 is built on) offers some key features which can be used for that functionality, so we'll be upgrading the site to the new version of Rails before the new translations code is implemented. This is a big task which affects code across the site, so it needs to be carefully scheduled.

We review our Roadmap every few years to consider our needs and priorities going forward. This post aims to provide an updated timeline of our major milestones: while we'll continue to be flexible and may implement things in a different order, this roadmap gives an overview of what we've got planned. If there are features not listed here which you'd like to see, please let us know in the comments to this post! You can also vote for suggested features on our Feature Requests Board - this helps us know what people would like us to prioritize (although sometimes other constraints mean we can't implement popular requests as fast as we'd like, or can't commit to adding them to the Archive at all).

The Road so Far...

If you're interested in how the Archive has developed over the years, you can see all the work we completed up until June 2010 on the previous version of our Roadmap: everything up to Version 0.7 had been completed at the time it was published. We've listed the highlights of the work we've done since then below; for more detailed information on exactly what we did when, you can browse our extensive Release Notes, going back to the very first code deploy.

Interlude: Rails 3

In November 2010, we updated our version of Rails to Rails 3. Rails is a web framework for application development; the code of the Archive uses Rails and its various code libraries as well as other open source frameworks and tools. (For more information, see our Technology Stack page.)

This update involved changes to almost every part of the Archive code and was a major undertaking! Updating to use this version gave us access to a whole host of better features, and ensured that the codebase as a whole stayed up-to-date - important for stability and maintainability.

Version 0.8

Version 0.8 included a huge number of changes and stretched over multiple code releases, because it covered so many complex and interrelated things. It was completed in July 2012 and included:

  • Lots of performance-enhancing features, including widescale improvements in caching across the site. We introduced Squid for whole-page caching, more granular caching for frequently updated elements such as comment numbers on works, the caching of indexes for searches and sorting, and much more. These performance improvements helped us accommodate a massive expansion in the number of users in 2012.
  • A major update to our site Javascript: we moved to using a more modern and flexible Javascript library, jQuery.
  • A major overhaul of all our CSS and frontend code, for greater maintainability and accessibility.
  • The introduction of site skins to enable users to customize the appearance of the site.
  • The introduction of work skins to allow users to use CSS to style their works.
  • The introduction of embeds for multimedia works (fannish video and audio works like vids, AMVs, or podfic).
  • The launch of email subscriptions for authors and works, and feeds for tags across the site, to make it easier for users to get updates about works they were interested in.
  • The introduction of a user stats page, including many often requested features such as the ability to compare the numbers of kudos and comments on different works.
  • A range of tools for our Open Doors team, enabling the import and maintenance of at-risk archives. The first archive to be imported using these tools was the Smallville Slash Archive.
  • Lots of improvements to our challenge functionality, including the introduction of prompt memes!

The Road Ahead

The following is a rough outline of our plans for the next few years. We haven't included a timeframe for these milestones - not even a very rough one - because experience has shown us that a whole number of factors can influence development speed and priorities. Plans for the 1.0 release and beyond are kept very high-level right now; we will post an updated, more detailed plan as we get closer to the finish line.

Version 0.9

The first major part of Version 0.9 was the launch of our new tag filters, along with a number of other significant changes to the underlying code of our search and browse features. The site had outgrown the old filters, which were causing performance issues, and the new code has proven more robust and more usable. It also enabled us to implement filtering for bookmarks, which was a long-needed first step on the way to making personal bookmarks a truly useful Archive feature.

Throughout this development cycle, we're also also focusing heavily on performance improvements and long-term scalability (that is, how easily the site can grow to accomodate new users). As part of this, we are making several hopefully invisible changes under the hood:

  • Upgrading to the latest version of Ruby on Rails.
  • Increasing the amount of caching we do throughout the site and ironing out any remaining issues related to caching.
  • Adding new hardware, and optimizing our server setup.

We already added some new servers in January 2013, and you can read more about plans for expansion in our post, Going forward - our server setup and plans, part of our 2013 Spotlight on Systems.

One major code change we'll make during this release will be the complete refactoring of our work model (the large chunk of code that deals with creating, posting, and managing works). For obvious reasons, this is one of the oldest parts of the code on the site, and it needs some major revisions to make it robust, maintainable and flexible going forward. This is a very knotty piece of work (internally we refer to the work model as Mordor) and will likely take a while to get right.

The refactoring of the work model is an essential part of one of our major priorities: moving towards true support for visual art as well as fannish audio and video on the Archive. Hosting different media types (e.g. enabling image or audio file uploads to our servers) is still some way in the future, but version 0.9 will include a number of enhancements aimed at making the site more suitable for diverse types of fanworks, including better search and posting tools for non text-based media. We already allow embeds of art, fan videos, and audio works, and the first major enhancement in this release cycle will be the option to specify a media type for your fanwork when posting (instead of relying on Additional Tags alone), and to filter by media type when browsing. At the same time, we will add options for posting and searching for non-fiction fanworks (fannish meta and other non-fiction types). Our aim will be to make it as easy as possible for users to find the kinds of fannish content they are interested in, and for creators to tag and categorize their works usefully.

We will also be focusing on our collections suite, including challenges and prompt memes, to fix remaining bugs, address usability problems, and improve documentation as well as performance.

  • Stability, performance, and scalability improvements
  • Improvements to searching and browsing, including better filtering for media type, category, and language
  • A new header and footer layout, for easier site navigation
  • Improvements to tag wrangling management features, and enhancements to the tagging system to allow for improved handling of international sources and fandoms
  • Refinements to the collection and challenge code, including major bug fixes for gift exchanges, prompt memes and tag sets
  • Review and rewrite of existing code to prepare for art, video, and audio posting, and non-fiction fanworks
  • Improvements to the handling of work relationships (remixes, translations, gifts...) across the site
  • Improved and expanded tools for Open Doors to allow for easier imports of at-risk archives


Within the 0.9 release cycle, we want to take some scheduled time to review and assess our code base, documentation, resources and plans. During this time, active development will be kept to an absolute minimum and we'll avoid launching any new features. We will continue to monitor the site for any emergencies and keep sending out invites to people on the waiting list, but will focus most of our attention on laying the groundwork for good stability going forward. This is something which we always try to factor into our plans, but during very busy periods it's easy to build up technical debt and harder to make sure everything is shipshape and well-documented. This interlude will help ensure both our code and our procedures are well organized and sustainable.

Version 0.10

In these code updates, we will build upon and enhance the multimedia support and interface translation features. Providing the Archive structure and navigation in any language, not just English, was one of our main goals when we started dreaming up plans: we will now make sure that all site elements are translatable and complete the necessary translation tools for volunteers. This is different from support for individual fanworks in languages other than English, which we hope will be vastly improved by the changes and bug fixes planned in version 0.9.

Additionally, more subscription options will be added, enabling users to keep track of exactly the kind of fanwork they want to read, look at, or listen to. Subscription management will be improved.

We will also make our admin system more robust and allow for clearly defined roles in site and user management, with improved admin features for each area (such as better tools for our Abuse staff).

In this release cycle, we will also add private messaging, one of the most-requested features.

  • Translation features for an Archive in many different languages
  • Private messaging features
  • More subscription options
  • Anonymous posting
  • Improved drafts management
  • Better chapter management, including the ability to indicate prologues and epilogues
  • Improvements to the History feature
  • Groundwork for a more modular admin system to spread out tasks (managing users, approving new public skins, posting news etc.) across distinct admin roles
  • Profile enhancements, such as the option to list your presence on other services (Dreamwidth, DeviantArt, etc) and offer beta services

Version 0.11

In our last planned release cycle before announcing 1.0, we will focus on ironing out any remaining bugs, review existing features, refactor and optimize our codebase for scalability and expandability, and make sure that, above all else, the Archive is accessible to all users. We will also review our wide range of automated tests to ensure that all our features have complementary test suites and that our testing framework adheres to current best practices before going forward.

Version 1.0 and beyond

Our goal for Release 1.0 is to have a stable package with all core features working well, and a full testing suite. This will provide a good foundation for the move to hosting fanwork files on our own servers, which will be a core goal for our post 1.0 development. It will also enable us to bundle an install package for easy installation by users without substantial systems experience. This will include the further enhancement of admin roles to allow a master admin and more site customisation settings. We also want to provide API hooks for developers to build upon our codebase for posting/bookmarking/reading/etc. tools and enhancements. A more structured outline of goals will be posted before we reach this biggest of milestones.

  • A robust feature set for posting, managing, and browsing different kinds of fanworks: text (such as fic or essays), images (such as fanart, graphics, or crafts), audio (such as podfic, audio fic, fannish songs, or filk), and video (such as AMVs and vids)
  • A translatable interface that makes it possible to customize the Archive for a variety of languages
  • A default interface that is functional, accessible, and attractive (in that order of importance) in a wide variety of browsers, platforms and assistive tech, and easily customizable for special needs and preferences
  • Public API
  • Release package

How You Can Help

The Organization for Transformative Works is always looking for volunteers to donate their time and skills (or alternatively, hard-earned cash) to the development of the Archive of Our Own. You can read more about how to contribute or get in touch with the Volunteers & Recruiting committee to offer your help. Depending on open positions, we will welcome skilled programmers, database specialists, sysadmins, designers, QA personnel and technical writers, as well as interested people who are new to coding and software testing. Training and support will be provided, so anyone can help shape the future of the Archive!


Fandom nonfiction: seeking feedback

Published: 2013-03-13 15:28:47 -0400

The Board’s decision on meta has sparked a great deal of conversation, externally and internally, and we appreciate the detailed comments many people have left. Over the course of internal discussions among the affected committees, we've determined that "fandom nonfiction" is a more useful term than “meta” to explain the kinds of works covered by the Board vote. We invite your feedback on these proposals. We will be collecting feedback for two weeks, and then will incorporate that feedback into a policy for Board approval.

Ultimately, we will handle many different kinds of fannish creativity through a work type system. However, while we hope to make progress on this later in the year, we do not have a definite timeframe for work types. In the interim, creators may choose to wait until work types are implemented or to use the additional tags to categorize their works in order to facilitate the transition to work types.

Important note: there are many key issues relating to the implementation of work type categories. We are only beginning to brainstorm on the technical aspects. If you give us feedback about what you want from the specifics of work type now, before we have a proposal on the table, we may miss it when we get into the technical aspects. So while we welcome your feedback, we ask that you focus it in this post on the general issues of policy: what we will host and what abilities administrators ought to have with respect to mislabeled works. Just by way of example: "Abuse should be able to recategorize a textual work from fiction to nonfiction" is feedback within the scope of the current proposal. "Visual art should be divided into digital, hand-drawn, and other" is not within the scope of the current proposal, though we will seek more input on these types of issues as we continue to develop the work type plan.

That said, here is a very general outline of what we are thinking:

(1) When creators post a work, some type of general "work type" selection will ultimately be mandatory, as choosing a rating and a warning or warnings are now mandatory. This will probably refer to functional file characteristics like text, video, and audio, but may also incorporate a fiction/nonfiction divide. Once the work types are available, as with ratings and warnings, our basic policy will be to defer to the creator's categorizations.

(2) Other aspects of work type will likely be optional/user-defined, possibly with autofill/some predetermined options that will not be exclusive. Again, our basic policy will be to defer to the creator’s categorizations.

(3) We may auto-detect some work features such as the presence of an image or image tag, the way we currently auto-detect word count.

(4) Where the AO3 already provides specific features for a particular kind of content—specifically, fanwork searches, bookmarks, and challenges—we will ask people to use those features for that content.

Your feedback on these general principles, as well as the more specific issues addressed below, is welcome.

How will existing works fit into this scheme or be moved into this scheme?: This is a technical issue that is not yet resolved. On the policy side, no one will be penalized for having posted a work that, because of the implementation of work type, is technically "mislabeled" as a result of the transition. However, we may try some automated solutions for detecting work type and/or ask creators to change a work type when they posted before work type was introduced. Part of the transition may thus be to automatically set work type based on the presence or absence of certain tags or other work features, then notify the creators and allow them to change the work type if the automated process made a mistake. Once work type is implemented, the current proposal is that administrators will have the ability to correct an obvious miscategorization of work type (that is, a case that is not borderline even after deference to the creator) if the creator fails to respond to an inquiry after a reasonable time.

We want to have definitions that can be reasonably explained and enforced by our dedicated volunteers. Our policy is to default to respect creators’ own characterizations of their works, and that will remain the case. Abuse will, however, be able to request the removal of or remove particular works when they are clearly beyond the scope of fandom nonfiction, just as Abuse can currently make other Terms of Service-related determinations in appropriate circumstances.

Draft FAQ additions:

Q: Is nonfiction allowed on the Archive?

A: Fandom nonfiction is allowed. Where we provide a specific function (search, bookmarking, challenges) we will ask you to use the specific methods we provide for those activities. In addition, as an archive whose goal is preservation, we want permanent, nonephemeral content. To the extent that your content is designed to be ephemeral, such as liveblogging episode reactions, it should go on a journaling service and not the Archive.

Q: What falls within the definition of fandom nonfiction?

A: Fandom nonfiction can be discussions of fannish tropes, commentary on fandoms, documentaries, podcasts about fandom, explanations of the creative process behind a fanwork or works, guides for fan-created gaming campaigns, or many other things.

However, the nature of the Archive and the limitations of our resources mean that, while we will endeavor to host as much fannish content as possible, we need to put some limits on allowable works. In particular, the Archive is not a journaling service and it is not designed to host ephemeral content.

We will, in general, defer to the creator’s characterization of a work as fandom nonfiction as long as it has a reasonably perceptible fannish connection, either to a specific source or to fandom in general, and takes the form of an independent, nonephemeral commentary. For example, an analysis of or commentary on multiple fanworks is nonfiction meta (and must comply with our other policies, including our harassment policy). An essay on a particular character's narrative arc in canon or of the interaction between film and comics versions of a source is also meta.

We understand that, as with many things, there are hard cases at the edges of categories, but we nonetheless need some limits in order to keep the Archive manageable for our hard-working volunteers as well as for other users.

Q: What about a fanwork search?

A: Please use our search functions for this rather than creating a separate work.

Q: What about a recommendation for a single fanwork?

A: Please use our bookmark/recommendation function for this; many creators also welcome discussion in the comments to the work, which is another appropriate place for such commentary. As always, while criticism of a fanwork is not itself harassment, content must comply with our other policies, including our harassment policy.

Q: What counts as a recommendation versus a more general discussion or analysis?

A: Please use your judgment on the best way to categorize a commentary. Our general policy is to defer to creators.

Q: How does the harassment policy apply to reviews?

A: The Terms of Service state “When judging whether a specific incident constitutes harassment, the abuse team will consider factors such as whether the behavior was repeated, whether it was repeated after the offender was asked to stop, whether the behavior was targeted at a specific person, whether that target could have easily avoided encountering the behavior, whether the behavior would be considered unacceptable according to normal community standards, etc.” This policy applies to reviews. Again, criticism of a fanwork, even harsh criticism, is not itself harassment. Calling a creator evil or wishing harm to them are potential examples of harassment.

Q: What about a fanwork prompt?

A: Please use our challenge function for this.

Q: What about a letter to someone I've been anonymously matched with for a challenge?

A: Since this content is designed to be ephemeral/nonpermanent, please put it on your profile, which can be edited to include your preferences.

Q: What isn't fandom nonfiction?

A: The examples are potentially limitless, but here are some examples that we believe, based on our experience so far, do not qualify as fandom nonfiction and should not be posted as a work:

  • episode transcripts and other non-transformative fandom material;
  • primarily autobiographical or non-fandom-related essays (e.g., essays on bike lanes, even if they contain a single reference to a fannish source);
  • general complaints about behavior towards a particular creator (e.g., a post stating that a work was deleted due to lack of feedback);
  • suggestions that other fans contact the creator through email or other social networks;
  • a single word or pairing name repeated hundreds of times;
  • offers and giveaways.

As with all works, we presume good faith on the part of our users, and ask that you do the same for the fans who make up our Support and Abuse teams.

Q: How will “ephemeral” be defined?

A: Please use your best judgment; our general policy is to defer to creators in cases of doubt. However, episode reactions of the type ‘OMG SAM’S HAIR OMG OMG. DEEEEEEEEEEEAN’ are likely to be appropriate for journaling services and not for the Archive. Ephemeral content is generally meant to be read at a particular time: for example, a message about a particular challenge or a reaction meant to be read while or just after a particular episode airs.

Proposed Terms of Service changes

The current ToS says: "Repeated identical posts in multiple places, e.g., a large number of identical comments promoting a website, will also be considered spam regardless of commercial content."

Proposed: "Repeated identical or nearly identical posts in multiple places, e.g., a large number of identical comments promoting a website, will also be considered spam regardless of commercial content."

Rationale: clarifying that small differences between posts will not be enough to take a series of posts out of the "spam" category. A creator who posts 25 different fanworks in quick succession as part of moving their output onto the Archive is not spamming, nor is a creator who posts 10 different drabbles (100-word stories), but 10 rapid-fire works with minimal content of any kind might be spam.

Current ToS:
K. Ratings and Warnings

K. Ratings, Warnings, and Fanwork Types

[new 5.] Fanwork types

It is our policy to defer to creators' categorizations, but we reserve the right to recategorize a fanwork type.

A manual recategorization decision made by the abuse team is appealable through the ordinary abuse appeals process.

A manual recategorization of a fanwork will not result in suspension of a user's account, unless it is a repeated pattern for a single user, in which case it may be treated as grounds for a suspension. Moreover, if a creator unilaterally reverses a manual recategorization, without agreement from the abuse team, that will be treated as grounds for a suspension.

Related FAQ additions:

Q: What do you mean by recategorizing a fanwork type?

A: For technical reasons relating to how our database is planned to evolve, we need for archive administrators to have the ability to change a work type where it is clearly appropriate (e.g., a review essay or fanvid mistakenly or inadvertently categorized as textual fiction). Because work type will be a new addition (and we may create new categories over time), we understand that users won't necessarily go back and change the work type on previously uploaded works. Inaction on already-existing works will not be grounds for any penalty for users, even if we do later ask that the work type be changed to reflect what it is. People will also make mistakes when work type is in place. Once work type is in place, our general policy when a recategorization is clearly appropriate will be to ask the user to recategorize the work, and change the work type if we receive no response. In addition, our general policy is to defer to the creator's choices in borderline cases.

Q: What do you mean by a manual recategorization?

A manual recategorization is an individualized determination that a specific work has been miscategorized, made as the result of a specific complaint. In terms of the transition to work types, we may automate work type detection for existing works, notify users, and ask them to change the work type if the automated process made a mistake. This automatic process would operate outside the abuse process, not as a manual recategorization.

Q: Will you recategorize or remove other tags, such as relationship tags?

A: Because our Abuse and Support resources are limited, and because different people interpret tags in many different ways, we don’t think that we can fairly enforce rules about relationship or other tags. We encourage users to engage with each other on these issues.


Pages Navigation