Dreamwidth Development

We've seen some questions lately about AI and how it relates to Dreamwidth, especially around scraping and training. Rather than answer piecemeal, I wanted to talk through how denise and I are thinking about this and try to be explicit about some things.

Dreamwidth is a user-supported service. We don't build the service around monetizing user data, and that informs how we approach AI just like it informs everything else we do.

Your content and AI training

Dreamwidth does not and will not sell, license, or otherwise provide user content for AI training. We have not and will not enter into data-access agreements for AI training purposes.

We will continue taking reasonable technical steps to discourage large-scale automated scraping, including known AI crawlers, where it is practical to do so. No public website can prevent scraping with absolute certainty, but we will keep doing what we reasonably can on our side.

AI features on Dreamwidth

Dreamwidth will not introduce AI features (and we have no current intention of doing so) that use or process user content without a public discussion with the community first.

We're only phrasing it like this because we can't predict the future and who knows what will be possible and available in five or ten years, but right now there's nothing we can see wanting to add.

If that ever changed, the conversation would happen openly before any decisions were made.

Site admin uses of AI

Keeping Dreamwidth usable means dealing with things like spam and abuse, and that sometimes requires automated admin tools to be more efficient or effective.

We are not currently using AI-driven systems for moderation or similar decisions.

If we ever decide that an AI-based tool would help address a site admin problem like spam, we will explain what we are doing and how it works (and ask for feedback!) before putting it into use. Any such tools would exist only to make it easier and more efficient for us to do the work of running the site.

AI and code contributions

Dreamwidth is an open-source project, and contributors use a variety of tools and workflows.

Contributors may choose whether or not to use AI-assisted tools when writing or reviewing code. Dreamwidth will not require contributors to use AI tools, and we will not reject contributions solely because AI-assisted tools were used.

For developers: if you use any AI-assisted development tools for generating a pull request or code contribution, we expect you to thoroughly and carefully review the output of those tools before including them in a pull request. We would ask the community not to submit pull requests from automated agents with no human intervention in the submission process.

I think it's important and I want to be able to review, understand, and maintain any contributions effectively, and that means humans are involved and making sure we're writing code for humans to work with, even if AI was involved.

Important note: this applies to code only. We expect any submitted images or artwork (such as for styles, mood themes, or anything else) to be the work of a human artist.

And to be very explicit, any AI-assisted development does not involve access to Dreamwidth posts or personal content.

In short summary

• Dreamwidth does not and will not provide user content for AI training
• Dreamwidth have not and will not enter data-sharing agreements for AI training and we will do what we can to prevent/discourage automated scraping by AI companies
• Dreamwidth will not introduce AI features without a public discussion first
• Any site admin use of AI tools will be explained openly and part of a public conversation
• Contributors can choose their own development tools for code, but we do not accept images or artwork generated by AI

Oh, and we'll probably mention this (or a subset of this that isn't code related) in an upcoming dw_news post, but will defer to denise on that!

Hi all,

We're here at OSCON (O'Reilly's Open Source Conference in Portland) with a bunch of the volunteers who work on Dreamwidth. Related to this, we've finally decided to force an upgrade to our Perl base version required.

kareila says it well:

Hello all! A few facts have recently come to our attention:

1) Perl 5.10 has a significant number of new, desirable features over Perl 5.8.

2) Perl 5.10 was released 5 years ago, so it's reasonable to assume most people are using Perl 5.10 or newer in production.

3) We are, in fact, using Perl 5.10 in production.

Therefore, we are planning to start requiring Perl 5.10 as we fix bugs and add new features in the future. If you are running a Dreamwidth installation on a version of Perl older than 5.10, now would be an excellent time to consider upgrading.

We are also considering moving to 5.12 or 5.14 soon. We need to do some more investigation and also validate the system on those versions. But for now, consider 5.10 as required.

Thanks!

Recently we had a bit of confusion in Bugzilla about exactly who does what, who's responsible for what, and when it might be appropriate to circumvent someone else's priority in order to get something done more quickly. (Read: step in on someone else's bug to fix something.)

The situation: let's say that denise writes a patch. Then afuna comes along and commits that patch. A week later, I push it live, woo! It turns out, oh noes!, there was a bug in that code that went live. Who is responsible for fixing this?

The short and correct answer is: once code has gone live on the site and contains a bug, it is everybody's responsibility to ensure a timely fix is made.

When it comes down to it, this is a balancing act between Dreamwidth the community project and Dreamwidth the business. We spend most of our time optimizing for the former because I believe that's the right thing to do. However, from time to time, we have to make concessions in the name of the latter. (Example, I'd much rather be working on some features right now, but I need to do the payment system. Also, The review queue needs some serious work, but alas, I have to deprioritize it for a little while!)

This balancing act comes to the front again when we talk about the difference between code that is still theoretical (in Bugzilla as patches) and code that is live and available for users to interact with. As soon as code is live, I expect anybody who can step in to fix problems to do so, and I expect people who submit patches to understand that once it goes live, they lose a lot of that ownership that they are given while working on it to begin with.

I don't want people being afraid to fix bugs because of code/bug ownership or interpersonal issues -- we're all on the same team here. We're all working together to make sure this site continues to be as amazing as it has been, to keep a wonderful home for us and our friends, etc etc. This is something that is going to take people working together to accomplish, and 'this is my bug, go away' can be counter-productive to those goals in some cases.

Now, also consider that it does depend somewhat on the severity of the bug in question. If it's a minor issue (colors/font wrong, text out of place, ugly, etc) then you should ask the original author first before you touch the bug and start fixing it. It's just polite. In this example, Denise put all her time into the original feature or fix, more than likely she feels bad that it was broken and would like the opportunity to fix it. If Afuna swoops in and fixes it, that hinders Denise's ability to learn and it doesn't let her fully resolve the issue. (If in doubt on priority, ask Denise or me -- we'll be happy to tell you.)

But, and I want to stress this again, the decision on priority is going to be one that is fuzzy. Denise may think the bug is not worth an immediate fix from someone else, but Afuna might think it is. If Afuna comes in and fixes it, then Denise might be annoyed, but Afuna did nothing wrong. If the priority was wrongly determined, feel free to point that out and discuss it, but let's avoid any anger and frustration: everybody here did the right thing and was working to the betterment of the site.

Does anybody have any thoughts on this subject? I'm happy to discuss it and try to find something that elegantly balances the priorities and needs of the project with the goals and desires of our development community.