If you're having a problem with Dreamwidth, please contact Support. I do regret that I can't reply to Dreamwidth-specific issues that are left as comments to this journal, in private message, or in email -- mark and I are tremendously swamped, and we need to redirect all issues, problems, and questions to the support board instead of trying to coordinate having reports in multiple places.
You can use the following categories:
Site Interface: If you're having a technical problem with Dreamwidth or you'd like to report a bug.
Importer: If you're having problems importing your content from another site.
Entries: If you're having problems with entries to your journal.
Styles: If you're having problems designing the look of your journal.
Account Payments: If you're having a problem with a payment for your account, or want to discuss bulk account creation. (Or, you can email accounts@dreamwidth.org.)
Terms of Service: If you believe another user has violated the Terms of Service, or would like clarification on any of the points of the Terms of Service. (Or, you can email abuse@dreamwidth.org.)
Feedback: If you'd like to provide an opinion on dreamwidth.org the service. (Or, you can email feedback@dreamwidth.org.)
Webmaster: If you need to contact site staff for any other reason. (Or, you can email webmaster@dreamwidth.org.)
You can make suggestions by using the site's Suggestions form, and read and review others' suggestions -- as well as talking over the best possible implementation -- in the dw_suggestions community!
I posted a thread on Twitter about potential legal liabilities for United States people who decide to run a Mastodon instance, and the response made it clear there's a lot of people who could use the extended background. So here is a guide to potential liability pitfalls for people who are running a Mastodon instance, and how to mitigate them. This is mostly US-specific, but I noted which things to think about are likely to apply worldwide. This is not legal advice and you should contact a lawyer licensed in your jurisdiction for the exact details of the liability you're exposed to and a detailed risk assessment.
This is not about just creating a Mastodon account: it's for people who are running a Mastodon server. If you just made an account on someone else's server, you can safely ignore this.
Mastodon calls each specific server an "instance". My Twitter thread made it super clear that people, even people who are running instances, don't know what this means, so having used the Mastodon technical language in the intro, I will now shift to calling them "servers" from here on out. (In several places I am using more commonly understood terms rather than the correct technical terms.)
I'm only addressing legal/liability issues, not the practicality of running a service. Things like "make backups", "keep backups offsite/on a different network", "try restoring from backup occasionally to make sure they're working", "evaluate every release of every new package installed on the machine you're hosting on to weigh security fixes vs potential for your platform breaking", "lock down the machine you're hosting on to minimize network intrusions", "what kind of content moderation policies you should have for social other than legal purposes" etc, are all outside the scope of this document.
A very kind internet lawyer on Twitter provided a few posts that you may want to read for this, although the second was written in 2010 and doesn't cover some of the other stuff I'm going to get into:
* Copywrong Again: Founding the Next Pinterest or Napster?
* If You Build It, They Will Abuse It
( A guide to potential liability pitfalls for running a Mastodon server in the US )
This is not about just creating a Mastodon account: it's for people who are running a Mastodon server. If you just made an account on someone else's server, you can safely ignore this.
Mastodon calls each specific server an "instance". My Twitter thread made it super clear that people, even people who are running instances, don't know what this means, so having used the Mastodon technical language in the intro, I will now shift to calling them "servers" from here on out. (In several places I am using more commonly understood terms rather than the correct technical terms.)
I'm only addressing legal/liability issues, not the practicality of running a service. Things like "make backups", "keep backups offsite/on a different network", "try restoring from backup occasionally to make sure they're working", "evaluate every release of every new package installed on the machine you're hosting on to weigh security fixes vs potential for your platform breaking", "lock down the machine you're hosting on to minimize network intrusions", "what kind of content moderation policies you should have for social other than legal purposes" etc, are all outside the scope of this document.
A very kind internet lawyer on Twitter provided a few posts that you may want to read for this, although the second was written in 2010 and doesn't cover some of the other stuff I'm going to get into:
* Copywrong Again: Founding the Next Pinterest or Napster?
* If You Build It, They Will Abuse It
( A guide to potential liability pitfalls for running a Mastodon server in the US )
(no subject)
Jul. 30th, 2015 12:45 amToday I found out that open source community member, feminist, activist, and fucking awesome human being Nóirín Plunkett has died. I have no words for what we've lost in losing Nóirín; I think the open source community is going to keep running headfirst into that loss for years to come.
Nóirín, wherever you are now, I hope it's full of everything you would consider paradise. It's going to be a long fucking time before I stop looking for you at every conference I go to.
Nóirín, wherever you are now, I hope it's full of everything you would consider paradise. It's going to be a long fucking time before I stop looking for you at every conference I go to.
My talk at this year's linux.conf.au was "When Your Codebase Is Nearly Old Enough To Vote": a case study of Dreamwidth and all the horrible horrible things we've found down there underneath the couch cushions, along with the lessons we've learned about when to rewrite them and when to leave them alone.
You can view the YouTube recording (sorry, no transcript), or check out the slides!
You can view the YouTube recording (sorry, no transcript), or check out the slides!
Let's spend Sumana's money!
Dec. 30th, 2014 04:23 pmStumptown Syndicate, the 501(c)(3) organization that puts on a bunch of wonderful events including Open Source Bridge (which is probably my favorite conference) is running a fundraiser right now, and the wonderful Sumana Harihareswara (aka brainwane) is offering a matching donation: she and her partner will match up to $15,000 donated before 1:30pm PST tomorrow (Dec 31).
Sumana's post goes into a lot of detail about why OSB and Stumptown Syndicate are worth giving money to. Like her, OSB is the tech conference I've found most welcoming. Now that I've been (last year was my second year) I'm going to make it a point of never missing it again, short of utter disaster. Unlike many conferences, it's about the whole open source ecosystem -- design, documentation, project management, and culture, in addition to programming. It's the most welcoming conference I've ever attended; I've never once felt out of place, marginalized, or uncomfortable there. Their speaker lineup is the most diverse of any conference I've ever seen. They're fabulous at all the small touches that make the event feel like they want everyone there, from taped-off accessibility travel lanes, to catering that takes all manner of diet, food sensitivities, and allergies into account, to a quiet room to hang out in, to inclusive language everywhere -- and so many more little touches that make it clear inclusiveness is a top priority. And, of course, they give back to the open source world in many other ways: all the tools they've developed to run the event are available under an open license, including Open Conference Ware, the engine that runs everything.
There are a lot of conferences in the tech world that I'll go to, but I'll go with my armor up, waiting to stumble over the thing that reminds me I am not what they think of when they think of their target audience. Going to OSB is something you can do without that armor, and once you show up, you get to spend four days hanging out with some of the most amazing people in the tech world and geeking out about the things you love. As Sumana says, this fundraiser will help to take OSB's already-awesome inclusiveness and help it level up: they're hoping to fund childcare, improve the accomodations for Deaf or hard of hearing folks, and enable scholarships and travel assistance for people who otherwise wouldn't be able to afford to attend. I think these are awesome goals!
So, if you have a few bucks you're not using, you can double their reach by donating now and unlocking more of Sumana's matching funds. And if you're looking for a great conference, OSB is running June 23-26 this year; I hope to see you there!
Sumana's post goes into a lot of detail about why OSB and Stumptown Syndicate are worth giving money to. Like her, OSB is the tech conference I've found most welcoming. Now that I've been (last year was my second year) I'm going to make it a point of never missing it again, short of utter disaster. Unlike many conferences, it's about the whole open source ecosystem -- design, documentation, project management, and culture, in addition to programming. It's the most welcoming conference I've ever attended; I've never once felt out of place, marginalized, or uncomfortable there. Their speaker lineup is the most diverse of any conference I've ever seen. They're fabulous at all the small touches that make the event feel like they want everyone there, from taped-off accessibility travel lanes, to catering that takes all manner of diet, food sensitivities, and allergies into account, to a quiet room to hang out in, to inclusive language everywhere -- and so many more little touches that make it clear inclusiveness is a top priority. And, of course, they give back to the open source world in many other ways: all the tools they've developed to run the event are available under an open license, including Open Conference Ware, the engine that runs everything.
There are a lot of conferences in the tech world that I'll go to, but I'll go with my armor up, waiting to stumble over the thing that reminds me I am not what they think of when they think of their target audience. Going to OSB is something you can do without that armor, and once you show up, you get to spend four days hanging out with some of the most amazing people in the tech world and geeking out about the things you love. As Sumana says, this fundraiser will help to take OSB's already-awesome inclusiveness and help it level up: they're hoping to fund childcare, improve the accomodations for Deaf or hard of hearing folks, and enable scholarships and travel assistance for people who otherwise wouldn't be able to afford to attend. I think these are awesome goals!
So, if you have a few bucks you're not using, you can double their reach by donating now and unlocking more of Sumana's matching funds. And if you're looking for a great conference, OSB is running June 23-26 this year; I hope to see you there!
Impostor syndrome
Jun. 27th, 2013 01:30 amI've been talking a lot at conferences this year about impostor syndrome, and if you're interested, the Ada Initiative has transcribed and captioned the talk I gave at linux.conf.au this year:
Kicking Impostor Syndrome In The Head: Lessons from AdaCamp DC and SF
This is the shorter version of the talk -- I gave the longer one at Open Source Bridge last week, and the slides for that one can be found at Kicking Impostor Syndrome In The Head. (The longer talk also includes a section on how you can help people around you with their impostor syndrome, especially if you're in a position of social or technical authority or status in your group or project.) I'm pretty sure video of that talk will be available at some point, too!
Kicking Impostor Syndrome In The Head: Lessons from AdaCamp DC and SF
This is the shorter version of the talk -- I gave the longer one at Open Source Bridge last week, and the slides for that one can be found at Kicking Impostor Syndrome In The Head. (The longer talk also includes a section on how you can help people around you with their impostor syndrome, especially if you're in a position of social or technical authority or status in your group or project.) I'm pretty sure video of that talk will be available at some point, too!
#dwgoestoyapc
Jun. 11th, 2013 03:20 pm(I need to email in these photos so I can link them from the news post!)
Photo #1: us outside our server hosting company, complete with bonus @dive and @cheyinka and their adorable tiny human. Photo #2: sunset over the Capitol building, as seen from our hotel room balcony. Both photos by the lovely and talented @sarah.
( ack, forgot the cut! )
Photo #1: us outside our server hosting company, complete with bonus @dive and @cheyinka and their adorable tiny human. Photo #2: sunset over the Capitol building, as seen from our hotel room balcony. Both photos by the lovely and talented @sarah.
( ack, forgot the cut! )
(no subject)
Mar. 18th, 2013 09:27 amapplications for adacamp san francisco (june 8-9) are now open!
adacamp is a two-day unconference for supporters of women in open technology and culture. if you are significantly female-identified (*) and into open stuff -- not just programming or technical matters, but any form of open data, open government, fan and remix culture, open education, open source, open technology, and so on -- you should really consider attending.
there's childcare available, too, if that would be a limiting factor! and there's (limited) travel funding you can apply for. the conference itself is "by invitation", but the invitation process is basically to make sure people have a basic level of awareness of feminism in order to get the most out of things and not be detrimental to the group as a whole; it's not there to exclude people who aren't "technical enough" (if you're reading this on the internet right now, you're technical enough). so if you're interested in hanging out for a weekend and talking with other women about open technology and culture, you should apply.
i went to adacamp dc and it was an awesome experience being around so many smart, interesting, engaging women. i'm not 100% sure yet whether or not i'm going to be able to go to this one, but if you can, you really should.
(*) based on feedback and requests, the main adacamp sf programming is restricted to women and people who are significantly female-identified. there's a parallel allies track for people of all other genders, being held on june 8. the ada initiative uses an inclusive definition of female-identified: if you identify primarily or significantly as a woman, you can register for the main track.
adacamp is a two-day unconference for supporters of women in open technology and culture. if you are significantly female-identified (*) and into open stuff -- not just programming or technical matters, but any form of open data, open government, fan and remix culture, open education, open source, open technology, and so on -- you should really consider attending.
there's childcare available, too, if that would be a limiting factor! and there's (limited) travel funding you can apply for. the conference itself is "by invitation", but the invitation process is basically to make sure people have a basic level of awareness of feminism in order to get the most out of things and not be detrimental to the group as a whole; it's not there to exclude people who aren't "technical enough" (if you're reading this on the internet right now, you're technical enough). so if you're interested in hanging out for a weekend and talking with other women about open technology and culture, you should apply.
i went to adacamp dc and it was an awesome experience being around so many smart, interesting, engaging women. i'm not 100% sure yet whether or not i'm going to be able to go to this one, but if you can, you really should.
(*) based on feedback and requests, the main adacamp sf programming is restricted to women and people who are significantly female-identified. there's a parallel allies track for people of all other genders, being held on june 8. the ada initiative uses an inclusive definition of female-identified: if you identify primarily or significantly as a woman, you can register for the main track.
bug counts are getting back in the saddle
Mar. 8th, 2013 02:01 pmit's been ages and ages since the last time i did a bug count post! (no, really, ages. the last one was over a year ago, eep!)
but i'm in the middle of working through a whole fuckton of bugzilla cleanup this week, and i thought i'd post a count at the midpoint. the "all open" numbers look scary, but they're down considerably from where we started at the beginning of the week, so i am ridiculously pleased!
All open: 897
All assigned: 181
All unassigned: 716
Bugs only: 572
Enhancements only: 325
All resolved: 4025
All resolved-fixed: 3462
(some of the queries have been removed, since we've moved to github for submitting patches, so the queries are no longer meaningful!)
of particular note: we have passed 4000 resolved bugs, and are approaching 3500 resolved/fixed!
but i'm in the middle of working through a whole fuckton of bugzilla cleanup this week, and i thought i'd post a count at the midpoint. the "all open" numbers look scary, but they're down considerably from where we started at the beginning of the week, so i am ridiculously pleased!
All open: 897
All assigned: 181
All unassigned: 716
Bugs only: 572
Enhancements only: 325
All resolved: 4025
All resolved-fixed: 3462
(some of the queries have been removed, since we've moved to github for submitting patches, so the queries are no longer meaningful!)
of particular note: we have passed 4000 resolved bugs, and are approaching 3500 resolved/fixed!
Thank you all for attending my talk! The slides are downloadable from Slideshare:
Web Accessibility for the 21st Century
This is the table of contents for the resource package, which contains:
If you have any questions that I didn't answer in the talk, or want to share some resources (or success stories after you go implement some of the advice!) please do comment!
Web Accessibility for the 21st Century
This is the table of contents for the resource package, which contains:
- 31 Quick Techniques to Make Your Site More Accessible: a text-only version of the 31 tips provided in the talk itself, so you don't have to mess around with transcribing them.
- Further Reading: A list of resources, further reading, and Useful Sites.
- Writing Useful Alt Text: An exercise for you to practice with! A handful of images, each presented with two different bits of text. Write the alt text for each image in each context.
- Writing Alt Text: Answers (and not-answers): My own answers to that exercise, and my reasoning for why -- these aren't definitive, because there are many different ways of doing it, but you can compare my answers with your own.
- Inaccessible (and annoying) Websites: A discussion in dw_accessibility where people name off examples of particularly inaccessible websites (and why they're inaccessible). I wound up not having time to fit that into this tutorial, but you can browse the comments and see the examples!
- Assistive Tech (semi-) Poll: A while back, we wound up asking people to comment in dw_accessibility with information about what assistive technology they use. The answers are fascinating, and demonstrate the wide variety of assistive tech out there.
- And dw_accessibility in general: this is the community for our accessibility project team, and you can read through both the general accessibility-related discussions and also see some examples of how we solicit accessibility-related feedback and design features to be as accessible as possible.
If you have any questions that I didn't answer in the talk, or want to share some resources (or success stories after you go implement some of the advice!) please do comment!
[tutorial] The 31 Tips
Jan. 31st, 2013 11:07 pmThese are the 31 points I covered in the talk, for ease of copy/pasting and not having to dig through and transcribe my slides! For those who haven't seen the talk, they'll probably be pretty understandable anyway, but you still need to see the talk to get the nuance. I am happy to come deliver this talk, or the longer version I cut this down from, to your local group ;)
( 31 Quick Techniques to Make Your Site More Accessible )
( 31 Quick Techniques to Make Your Site More Accessible )
[tutorial] Further Reading
Jan. 31st, 2013 11:00 pmHere's a list of a whole bunch of resources, tools, and information for you to do more reading about accessibility and accessible design. (This was done with the help of the dw_accessibility community, who are a bunch of very lovely people!)
They're roughly divided into categories, more or less.
If there's something I've missed, or another tool or resource you're fond of, leave a comment! (If you're commenting anonymously, or logged in with OpenID, you can leave links in the comments, but they'll be rewritten to display as bolded text followed by bare URLs: that's an antispam feature. I'll try to come through behind people and turn them into clickable links. Or you could create a Dreamwidth account!)
( Further Reading )
They're roughly divided into categories, more or less.
If there's something I've missed, or another tool or resource you're fond of, leave a comment! (If you're commenting anonymously, or logged in with OpenID, you can leave links in the comments, but they'll be rewritten to display as bolded text followed by bare URLs: that's an antispam feature. I'll try to come through behind people and turn them into clickable links. Or you could create a Dreamwidth account!)
( Further Reading )
Here are my answers to the Writing Alt Text exercise, and my reasoning for why on each.
You may disagree with me on many or any of the image descriptions! That's okay (and expected). As I said in the talk, many of these questions don't have a single answer, or have multiple possible answers, and people will disagree as to which one is better or best. So if you're worried because your answer isn't close to mine, that's fine: think about your reasoning, consider the basic principles and the desired goal, and work from there.
And, of course, if anybody wants to share their answers because they like theirs better than mine, feel free!
( My answers to the alt text exercise )
You may disagree with me on many or any of the image descriptions! That's okay (and expected). As I said in the talk, many of these questions don't have a single answer, or have multiple possible answers, and people will disagree as to which one is better or best. So if you're worried because your answer isn't close to mine, that's fine: think about your reasoning, consider the basic principles and the desired goal, and work from there.
And, of course, if anybody wants to share their answers because they like theirs better than mine, feel free!
( My answers to the alt text exercise )
[tutorial] Writing Alt Text
Jan. 31st, 2013 12:40 amWriting good alt text is an art, not a science. The same image can be described in different ways based on context, flow, and what aspects of the image you want to call to a listener's attention. The WHAT WG HTML Living Standard "4.8.1.1. Requirements for providing text to act as an alternative for images" has a collection of requirements for alt text, and WebAIM has a whole article on Appropriate Use of Alternative Text -- both of these are very useful resources! But it still takes practice to get really good at it.
So, let's practice, and see ways in which the same image in two different contexts might make you want to write the alt text differently.
Each of these sample images has two sets of text next to it: one formally-written piece (unless otherwise cited, it's from a relevant Wikipedia article), and a more casually-written sample that might be a blog post in which the image would appear.
Your task, should you choose to accept it, is to write relevant and useful alt text for the image in each context. Don't just look at the image and think in your head "oh, I'd do blah blah": actually write it out!
As you work, think about the differences in how you write the alt text in each context, and how different uses of the image make you want to call attention to different aspects of the image contents.
At the bottom of the page is a link to my version of the answers, with a brief explanation for each. I will reiterate that my answer is not necessarily everyone's answer! There are many, many ways to write alt text, and many people disagree as to which is the most useful.
Screenreader users: please note that I'm just using the alt text provided by Flickr's "get this HTML code" here, to avoid giving too many clues. Non-screenreader users: please don't just take Flickr's "get this HTML code" without altering it; it defaults to the title of the picture, which is usually fairly unhelpful for descriptive purposes!
I've turned comments off on this particular post, but they're open on the "answers" page, and if people would like to discuss their choices (or why they don't agree with my choices), feel free.
( Take the alt-text practice exercise! )
So, let's practice, and see ways in which the same image in two different contexts might make you want to write the alt text differently.
Each of these sample images has two sets of text next to it: one formally-written piece (unless otherwise cited, it's from a relevant Wikipedia article), and a more casually-written sample that might be a blog post in which the image would appear.
Your task, should you choose to accept it, is to write relevant and useful alt text for the image in each context. Don't just look at the image and think in your head "oh, I'd do blah blah": actually write it out!
As you work, think about the differences in how you write the alt text in each context, and how different uses of the image make you want to call attention to different aspects of the image contents.
At the bottom of the page is a link to my version of the answers, with a brief explanation for each. I will reiterate that my answer is not necessarily everyone's answer! There are many, many ways to write alt text, and many people disagree as to which is the most useful.
Screenreader users: please note that I'm just using the alt text provided by Flickr's "get this HTML code" here, to avoid giving too many clues. Non-screenreader users: please don't just take Flickr's "get this HTML code" without altering it; it defaults to the title of the picture, which is usually fairly unhelpful for descriptive purposes!
I've turned comments off on this particular post, but they're open on the "answers" page, and if people would like to discuss their choices (or why they don't agree with my choices), feel free.
( Take the alt-text practice exercise! )
Both mark and I got notice this afternoon that our proposed tutorials have been accepted for LinuxConf Australia in Canberra in January!
I will be giving (with help from deborah on the development thereof, but alas, she had a conflict with the conference itself) a one and a half hour tutorial called "Beyond Alt Text: What Every Project Should Know About Accessibility":
( working description of tutorial! )
I'm totally looking forward to it. We went to LCA a few years back (the year it was held in Wellington) and it was a fabulous conference full of fabulous people talking about smart and fabulous things. I'm looking forward to being able to return.
I will be giving (with help from deborah on the development thereof, but alas, she had a conflict with the conference itself) a one and a half hour tutorial called "Beyond Alt Text: What Every Project Should Know About Accessibility":
( working description of tutorial! )
I'm totally looking forward to it. We went to LCA a few years back (the year it was held in Wellington) and it was a fabulous conference full of fabulous people talking about smart and fabulous things. I'm looking forward to being able to return.
(no subject)
Jul. 21st, 2012 02:52 amAwesomeness: load the Latest Things page and see so many posts that are like "I'm testing out email posting so I can try the first draft of file hosting!" We released this way because it was soooo much easier (seriously, "upload from file" is a pain in the goddamn ass to do right and really easily to do badly) but the side effect of spotlighting one of our lesser-known features is kind of great.
Less awesomeness: a full week of trying to shoehorn myself into a 24-hour sleep schedule means that despite having woken up at a reasonable-ish time today, I am sitting here WIDE AWAKE and the alarm will be going off in four and a half hours for breakfast, last bits of packing, and heading to the airport :(
Not awesome at all: having to go back home and leaving behind all the amazing energy, enthusiasm, and excitement that comes from having ten people all sitting in a room hacking on DW. We are totally doing this again sometime.
Less awesomeness: a full week of trying to shoehorn myself into a 24-hour sleep schedule means that despite having woken up at a reasonable-ish time today, I am sitting here WIDE AWAKE and the alarm will be going off in four and a half hours for breakfast, last bits of packing, and heading to the airport :(
Not awesome at all: having to go back home and leaving behind all the amazing energy, enthusiasm, and excitement that comes from having ten people all sitting in a room hacking on DW. We are totally doing this again sometime.
The only real problem...
Jul. 19th, 2012 01:04 am...with having so many of our contributors here for OSCON is that we have to balance "going to talks and conference sessions to learn awesome things" with "hunkering down on the couches and tables in the hotel lobby and hacking on awesome things".
(Things that people are or have been hacking on this week: image hosting; HTML5/jQuery/responsive-design etc mobile page; "fuzzy" feed matching so there will be fewer duplicate feed accounts and allowing for a "did you mean?" suggestion when creating a feed; extra icon add-ons; the bookmarks/memories overhaul; HTML5, responsive-design site skin; "clean up ALLLLLL the tiny bugs!" (that would be me!); backend/site-reliability stuff; upgrading the code to run on Perl 5.14 ... I'm pretty sure I'm missing stuff, too. Heh.)
(Things that people are or have been hacking on this week: image hosting; HTML5/jQuery/responsive-design etc mobile page; "fuzzy" feed matching so there will be fewer duplicate feed accounts and allowing for a "did you mean?" suggestion when creating a feed; extra icon add-ons; the bookmarks/memories overhaul; HTML5, responsive-design site skin; "clean up ALLLLLL the tiny bugs!" (that would be me!); backend/site-reliability stuff; upgrading the code to run on Perl 5.14 ... I'm pretty sure I'm missing stuff, too. Heh.)