I just requested that Facebook permanently delete my account.
This change is a long time coming. I’ve grown increasingly concerned about the power Facebook exercises to commodify and influence our social interactions. There’s nothing holding Facebook accountable in the exercise of this power. Aside from all of that, I get very little out of time spent on the site. Yes, it’s a way I can connect with some folks for which I’m not in the habit of calling, emailing or writing. There’s nothing stopping me from doing this, however. I have the phone numbers, emails and addresses of the folks I generally care about keeping in touch with. I do wish more folks had their own blogs, though.
Earlier in the week I posted a message on my timeline telling folks that in a few days I’d be deleting my account. I listed a few other ways to get in touch with me including twitter, my blog, and email. The other thing I did was look at the settings for every Facebook page I’m an admin on and ensure I wasn’t the only one (I wasn’t). I also downloaded a copy of my info.
Today I logged in, ready to delete my account. First I couldn’t find a way to do so. I noticed a “deactivate my account” link under security settings. I figured this was the only way, so I tried it first.
When you try to deactivate your account, Facebook presents you with a page that does everything to try and get you to keep your account active. It shows you pictures of your friends, says they will miss you and prompts you to message them. I found it particularly funny that one of the friends it showed me was Creepius the Bear (and identity created to demonstrate how creepy one can be on Facebook):
And then after this you must provide a reason you’re deactivating your account. For any reason you select, you’re given additional information that supposedly resolves the concern:
What caught my attention was the Email opt out option, which states:
Note: Even after you deactivate, your friends can still invite you to events, tag you in photos, or ask you to join groups.
Not what I wanted, so I started figuring out how to work around this. Unfriend everyone first? Sounds tedious. Then someone asks me in IRC, “why don’t you delete instead of deactivate?” I responded saying I didn’t know that was an option. So, I searched Facebook’s help for “deactivate my account” and found this help page: How do I permanently delete my account?
I follow the link in that article, and got this prompt:
Much nicer, right? No guilt-trips and attempts to invalidate address my concerns. I clicked “Delete My Account”, filled out my password and captcha and got the following confirmation:
I also received confirmation via email.
So, that’s it! Assuming I don’t log in to my account during the next 14 days, my account will be deleted. Ah, freedom!
If you like the idea of doing this, but want a more gradual approach, check out de-facing, in which one person talks about their plan to leave Facebook one friend at a time.
While I don’t hear about it a lot recently these days, there are still some sites that I need OpenID to log in to. I had been using myOpenID from Janrain for this, but that service was retired. Unfortunately, So was my backup provider, ClaimID.
So, I went shopping for new providers! Here’s what I found:
Whatever OpenID provider you have, I highly suggest setting up delegation. OpenID delegation means you can use any website you control as your OpenID login. The delegate website is configured to use your chosen provider and you can switch anytime without having to update your login information on other sites.
How do you set up delegation? It’s easy! You just have to add the following two lines to the head of the site you want to act as delegate:
Replacing “mywebsite.com” with the site you want to act as delegate, and “myopenidprovider.com” with your chosen OpenID provider (e.g., openid.stackexchange.com). Make sure you have an account at the OpenID provider of your choice before doing this.
If you have a self-hosted WordPress blog, you can use this plugin instead of editing your theme files.
Yesterday, nearly four years after our religious ceremony, Sherri and I became legally married. I am so incredibly happy and proud to be able to call Sherri my legal spouse, and me hers, with all the rights and responsibilities therein.
The ceremony was brief, at our home, with a few clothes friends and family members in attendance.
These are the words I spoke to Sherri:
Not quite 7 years ago, I set out for Portland to start a new part of my life. Someone, or something must have been aware of my plan, because I was guided to you shortly upon my arrival here.
Since then I have learned that you are one of the most generous, compassionate and courageous spirits I have ever met. From the beginning, you opened your heart wide to me and while cautious at first, I have learned to take great refuge in your presence.
As many here know, the last handful of years together has been difficult. But between the challenges we’ve faced, we’ve found space for joy, laughter, and delight. I would do everything all over again for the privileged of getting to build this life with you.
My vows to you:
Because our life together will not always be easy, I vow to meet challenges in our relationship with a sense of compassion and adventure.
Because our family is but one piece in a very large puzzle. I vow to live a life of service to you, to our marriage and to our community.
Because while love is not scarce, many resources are, I vow to make sure you always have the things you need most such as food, water, shelter and art supplies. I vow to utilize our resources wisely.
Because I want to spend the most amount of time possible with you and grow old together, I vow to care for my body and mind.
Because play is just as important as work, I vow to cultivate playfulness, laughter and lightness in our relationship.
Because what I was hiding, deep inside, you brought out into the light, and even thought it is terrifying at times, I vow to stand bravely in the light of your love.
My dearest Sherri, You are the first person who made me truly feel loved. I look forward to sharing a life of practice with you and I am truly honored that you are recognizing again this commitment with me here today, in front of our friends and family.
While I wish we didn’t have to wait at all to get legally married, I’m grateful we have been able to do so in our home state earlier than I had anticipated. I’m grateful for the opportunity affirm “yes, I know what these vows mean in practice and I continue to commit to every single one of them.”
The Ursula K Le Guin quote that Sherri sent out with our invitations says it all:
Love does not just sit there, like a stone; it had to be made, like bread, remade all the time, made new.
For some time now the Mozilla Wiki has been significant amounts of spam. To give you an idea of the magnitude of the problem: hundreds of spam accounts are created every week and a handful of admins each spend upwards of 4 hours per week identifying and deleting spam content and accounts.
To combat this problem, we have have implemented a change to the way user accounts are created.
Prior to this change, anyone could create an account and immediately start editing pages. After a short interval, a new user was then able to create pages as well.
Now, all new users are required to request an account and have that request approved prior to logging in and editing or creating pages.
We expect the impact of this change to valid users to be minimal. During a typical week, only a handful of legitimate user accounts are created. The rest are spam.
Below you’ll find a list of questions and answers to help aid in this transition. If you have any questions that we have not answered, please let us know.
Thank you to everyone who helped implement this change, including: Jake Maul, Jason Crowe, AlisonW, KaiRo, and Gordon Hemsley, as well as all those who agreed to help approve accounts.
What is the work-flow for new users?
The new work-flow for new users is as follows:
A user visits the Mozilla Wiki and clicks Log in / create account
Users that don’t already have an account will click request one
On the request account page, the user will enter their preferred username, email address, name, bio, and additional information about themselves (optional).
After the user submits their request, they will receive an email asking them to confirm their email via a link. The user clicks on that link and their email is then confirmed.
Once the user’s request is approved, they will receive an email notification that includes a temporary password. They will be required to change their password the first time they log in to the wiki
Is the work-flow different for users who have accounts already?
No, those users will login as they always have.
What is the new work-flow for bureaucrats?
Once the user has confirmed their email, a notice of the request is sent to designated wiki users (a notice is also included on the RecentChanges and Watchlist pages for users who have the ability to approve).
The bureaucrat reviews the user’s account request and takes one of the following actions: approves, holds, or denies. Bureaucrats are instructed to approve all users they can reasonable verify are people with legitimate reason to edit the wiki (that is, not spammers or bots).
What should I do if my request has not been approved withing 24-48 hours?
Please email email@example.com or find us on IRC in #wiki.
What should I do if I am involved in a Mozilla-related event which is likely to generate many timely user account requests?
Please email firstname.lastname@example.org or find us on IRC in #wiki to let us know. We’ll do our best to have someone on hand during your event to approve requests.
Alternatively, we can create accounts for users ahead of time.
Why am I still encountering spam on the wiki?
The volume of spam received by the Mozilla Wiki has been such that we’ve not always be able to keep up with it. The change we have made to new user account creation affects the creation of new spam, but does not address preexisting spam content. We will continue to work on identifying and removing content. If you see a page that is clearly spam, let us know via IRC in #wiki.
How can I get involved with improving the Wiki?
The best way to get involved with improving the wiki is to join the Wiki Working Group (and we’d love to have you!).
Recently I’ve been thinking a lot about how to make more time for meaningful project work as well as for rest. One way to free up time has been to significantly reduce the number of meetings I attend and facilitate, and to make those meetings as efficient as possible when I do attend.
Idea 1: Only schedule meetings when there are no other effective options.
Meetings take up a lot of time. An hour long meeting doesn’t just take an hour, it takes an hour per person who attends the meeting. There’s also an opportunity cost associated with meetings. When you’re in meetings, you aren’t getting any other work done. The opportunity cost is multiplied if you have work that that requires long blocks of uninterrupted time. On days where I an hour of free time interspersed between meetings are days where I completed nothing but superficial tasks.
In general, always aim for fewer meetings. Before scheduling a meeting, ask yourself what the goal of the meeting is, and can that goal be accomplished in another, preferably asynchronous way.
There’s a caveat to this idea, however. If while discussing a topic in an asynchronous channel and you realize going round and round without progress or are otherwise not making progress, it’s time to move to a synchronous channel. This might be a video or telephone call or an IRC chat.
Idea 2: Schedule the shortest meeting possible.
Think about your goal, the number of people attending and then pick a meeting length accordingly. Many people default to hour long meetings for no other reason than it’s the default of many calendaring tools, and we’re used to thinking in full-hour increments. Take a look at your agenda. Do you need a full hour to get through it? Would 30 or 45 minutes work instead? Treat people’s time as the valuable and finite thing that it is and only ask for what you absolutely need.
Idea 3: Use a calendar tool to create and send a meeting invite.
Zimbra, Thunderbird via Lightning, iCal, Google Calendar, Outlook. Most email clients have this built in, so you shouldn’t have to think too hard and nor should your recipients. If you’re self-hosting email or on an otherwise non-mainstream hosted email, you probably have enough technical savvy to figure out how to send a calendar invite. Why? For those of us who live and die by our calendars, if something is not on there, it isn’t happening. Or it is, but I don’t need to know about it. Sending a calendar invite bypasses my often overwhelmed email queue and gives me the opportunity to respond in a routinized way without having to get to inbox zero.
Idea 4: Only invite those who really need to attend.
Call out attendees who are truly optional (many calendar tools have this feature, if not, use the invite body). Your agenda should give an good indication to invited attendees why they need to attend. Keep an eye out for acceptances and declines and follow-up accordingly. Don’t wait until the meeting has started to try and track down a necessary participant who didn’t respond to your meeting invite.
Idea 5: Manage large, group meetings using shared calendars instead of individual invites.
In the case of large, group meetings, I recommend using shared calendars instead of sending invitations to individuals or even groups of individuals. These work best for meetings where attendance is medium to very large, attendance is optional and variable, and the content of the meetings are largely updates with room for discussion. Using shared calendars allows people to subscribe to the calendars of events or groups for which they are interested in participating and gives them control over how to manage that information in their own calendars. With a shared calendar, a person can toggle visibility and choose whether or not those appointments will affect their free/busy status without having to respond to individual invites.
Idea 6: Share your own calendar whenever possible
Sharing your own calendar allows others to initiate meetings with you without having to go back and forth via email asking ‘what time is good.’ Doodle and other websites accomplish similar things, but take time to setup. If you share your calendar publicly and let people know about it, they can compare it with their own schedules and send an invite for a time that seems to work for both of you. If the time doesn’t actually work for you, you can decline or respond suggesting a new time. You won’t necessarily eliminate the back-and-forth with this method, but at least you’re a step closer. When someone sends you an invite, your time is blocked as tentative and there’s less of a chance you’ll be booked for something just after you’ve told someone via email you were free at that time.
What about privacy? Most calendars allow you to set not only the visibility of individual appointments (private vs public), but also to what extent you share the details of your calendar. Here’s what my public calendar , which is a combination of my personal and work calendars, looks like:
I’ve chosen to share only the free/busy status of my calendar, so all you see are blocks of time say ‘busy’ and ‘tentative’ depending on how I’ve responded to appointments. For me, this is a good mix of privacy vs the convenience of easier scheduling with other people.
Idea 7: Respond to meeting invites timely and accordingly
Whenever possible, respond to meeting invites timely and accordingly. This means accepting, declining or tentatively accepting invites that you receive. What constitutes ‘timely’ here is contextual. When I receive the initial invitation for a regular recurring meeting, I either accept all as tentative (thus blocking my schedule) or do nothing. Then at the beginning of each week, I look 2-3 weeks ahead and make sure I’ve either accepted or declined according to my availability. For meetings happening on the same day as I receive the invite, I try to accept or decline as soon as I see the invitation. For meetings happening within the week, I try to respond the same day I receive the invite. If I don’t know whether or not I can attend, I respond with a tentative acceptance and often provide the reason or a clarifying question: “I most likely have a conflict at this time, but could potentially move it. How important am I to this discussion?”
What are you strategies?
What strategies do you have to make scheduling easier, better, more productive? Leave them in the comments. Or tweet at me.
The community building curriculum subgroup had its first meeting (notes)! During the meeting we brainstormed what kind of community building curriculum could be possible to roll-out this year. We agreed that finding existing curriculum and adapting for Mozilla would be the best way to utilize our limited resources. Between this meeting and next, we’re going to make a list of possible resources to adapt
A community building skills question is prepared in Mozilla Moderator and after seeing with responses from the MozCamp design session in April, I’ll announce project-wide and ask for Mozillians to submit their ideas.
As always, you are welcome to join me in any of these projects. Look at my mozillians profile for the best way to get in touch with me.
One issue to emerge for last December’s Community Building meet-up was how important the Mozilla Wiki is to the project and also how neglected a resource it is. The Wiki Working Group was formed to address this issue. Since then, the Mozilla Wiki has become an official sub-module of Websites, we’ve fixed a handful of long-standing bugs, and we’re working on short- and long-term roadmaps for the wiki.
During our discussions about the wiki, we discovered the need for a clear statement about the purpose of the wiki, its role and importance to the project, what content belongs on the wiki (vs MDN, vs SUMO, etc.), and its governance structure. As such, we have drafted an About page that attempts to do those things.
We’d like for as many Mozillians as possible to read our draft and comment on it. When reviewing, we ask you to consider the following questions:
what about the content does or does not make sense to you?
what about the content does or does not resonate with you?
to what extent does the content match your vision for wiki.mozilla.org?
to what extent can you support the purpose, scope and governance structured described?
The comment period is open until 26 May 2014 at 14:00 UTC. Those comments will be considered and incorporated and this page adopted into the wiki by 15 June 2014.
Thank you to everyone from the Wiki Working Group who contributed to this document, especially: Lyre Calliope, Gordon Hemsley, Justin Crawford, Larissa Shapiro, Jennie Rose Halperin, Mark A. Hershberger, and Jason Crowe.
This is meant to be a quick reference, one that project leaders can read and understand quickly, and reference as they set up their projects.
Please take a look at the draft on WikiMo and let me know what you think. For best collaboration, leave your comments directly on that wiki page. Otherwise leave a comment here on the blog, or visit my Mozillians profile for the best way to get in touch.
This doesn’t fit specifically in either category below, but I still wanted to call attention to it: Last Tuesday we launched Firefox 29 “Australis,” our biggest redesign of Firefox since version 4!
Education & Culture Working Group
Further planning with Dino Anderson about diversity & inclusion efforts we’d like to roll out this year. I don’t have notes I can share, but will work on putting together some kind of update soon.
Drafted an open planning checklist (comments welcome!). This is geared towards all Mozilla teams (of paid and volunteer contributors) to help them adopt and maintain an open planning process.
Represented the E&C Working Group at the Grow Mozilla meeting.
Facilitated our regular Education & Culture working group meeting (notes).
Wiki Working Group
Triaged all open Websites::wiki.mozilla.org bugs. Closed 43 bugs (search).
Setup the wiki as a project in scrumbugs. Still updating bugs with user stories, so you won’t see a lot there, except in the backlog.
Worked, with Lyre and Larissa, on final drafts of wiki.mozilla.org and WWG purpose and scope documents. We’ll review as a group tomorrow and then I’ll post publicly.
I wrote a tiny, simple WordPress plugin called bz shortcode to help make generating individual bugzilla.mozilla.org links on this blog easier.
I’m trying to attend fewer meetings so that I have more time to work. My strategy so far is: If I receive a meeting invite without an agenda item making it clear why I’m a necessary participant, I’ve started declining with a note to the organizer asking if I really need to be there. The flip side of this is that I’m doing my best to have clear agendas a head of time for the meetings that I facilitate.
Priorities for this week
Finalize scope documents for both the wiki itself and the wiki working group.
Note: This is the first in what I plan to be weekly updates about the work we’re doing as part of the Education and Wiki Working Groups, part of the community building team at Mozilla. I’ll tag these updates with mozilla as well as cbt-education and wwg when appropriate.
Wiki Working Group
On Tuesday of last week we help our twice-monthly Wiki Working Group meeting (notes). Key takeaways:
We celebrated becoming an official sub-module of websites.
We talked about planning an in-person meet-up and sprint at this year’s Wikimania in London.
We talked about the need to clarify our vision for the wiki as a prerequisite for creating the long-term roadmap, as well as the need start on a short-term roadmap to address critical needs.
During our next meeting we’ll continue work on both the short- and long-term roadmaps. If you’re interested in contributing, please get involved!
Later in the week, a few of us fixed the following bugs:
Bug 858844 – Sortable tables on wiki no longer sortable
Bug 1001710 – Recent changes to wiki.mozilla.org break bugzilla plugin
Bug 819708 – wiki.mozilla.org editor wont show rich text editor
MozCamp Planing Session
Last week a handful of contributors gathered at the San Francisco office to plan MozCamps 2014, the next phase of what we’re still calling “MozCamps” but which we plan to evolve into a new kind of event.
I’m still synthesizing everything we covered during the planning session, but the most relevant takeaway in terms of the education working group was this list of community building skills that the group generating during a brainstorming session about what content should be included in the new MozCamps. This week I’m working to integrate that list into the existing community building curriculum roadmap.