Lukas Blakk

(Written by J Wallace, re-posted with permission)

Periodically, I get asked if there are more gender independent/ gender non-conforming/gender imaginative/ gender creative/gender variant/ transgender/ trans children and youth because there is more awareness of transpeople and trans-identities in society.

The answer is always no.

More awareness may mean more legal protections, and it may mean that there are more caring adults willing to support children and youth, but knowledge of transpeople does not make children up and decide that their own gender or sex needs to be changed. Even if it did (which it does not) I'd like to suggest that there is very little cultural material for children about transpeople. Carly, She's still My Daddy is just not showing up in many kindergarten libraries. And while there are children who read 10,000 Dresses and think "I'm just like the main character" it's not like the image it paints is so alluring that other children are going to think "hey, that's not me but I wish it was". The images of trans people that young children are exposed to are few, hard to find, and seldom positive. I dream of the day that resources like Reflection Press' Gender Now Coloring Book are more widely available, and even when they are, more awareness is not going to create more trans children.

The claim that there are more gender independent/ gender non-conforming/gender imaginative/ gender creative/gender variant/ transgender/ trans children and youth because here is more awareness of transpeople and trans-identities in society, is the polite way of saying "we recruit" and it's a slander that plays into the primal fear that "we are out to get your children". The myth that faeries would steal unbaptized children persists, and I remember being told that if I was bad, the gypsies would come take me away. The culture that I am a part of has a long history of claiming that those it wants to other will 'steal the children'. The antisemitic belief that Jews steal children to make Passover matza is a gross and disturbing example, but the idea that "we are out to get the children" has been proven over and over again as a successful way to villianize whole people. We the othered then have to spend time defending ourselves, and proving that we are not out to get your children. Often we are told that the way to do this is to act as much like the majority culture as possible and to be quiet. Talk about silencing marginalized voices.

The idea that there are more (and younger) trans people because of greater awareness of trans people also serves to distracts us from what is actually going on. Peggy Orenstein in Cinderella Ate My Daughter, documents a huge cultural shift towards an increasingly rigid gendering of childhood and children. She discusses at some length the marketing brilliance of clearly defining "boys toys" and "girls toys" and how doing so means that fewer older siblings are sharing their toys with differently gendered younger siblings and thus more toys are being sold. I frequently remind teachers that childhood now is more gendered than it was when we were children. I was born in the mid seventies and grew-up with Free to Be You and Me. While the message was that "every boy in this land grows to be his own man, every girl in this land grows to be her own women" and not "everyone gets to figure out who they are and then live that way" there was more room in the categories of "girl" and "boy". I could refuse to wear dresses, mostly play with boys, try-out and play on boys sports teams, and my behaviour was seen as "feminist" or that of a "tomboy", and inside the category of girl.

The other thing that has been happening at the same time, has been happening in the DSM. The DSM III first introduced a childhood diagnosis, Gender Identity Disorder in Childhood in 1980, and at the time it required:

Table 1 DSM-III diagnostic criteria for Gender Identity Disorder of Childhood
     For females
     A. Strongly and persistently stated desire to be a boy, or insistence that she is a boy (not merely a desire for any perceived
     cultural advantages from being a boy)
     B. Persistent repudiation of female anatomic structures, as manifested by at least one of the following repeated assertions
     (1) that she will grow up to become a man (not merely in role)
     (2) that she is biologically unable to become pregnant
     (3) that she will not develop breasts
     (4) that she has no vagina
     (5) that she has, or will grow, a penis
     C. Onset of the disturbance before puberty ...

     For males
     A. Strongly and persistently stated desire to be a girl, or insistence that he is a girl.
     B. Either (1) or (2)
     (1) persistent repudiation of male anatomic structures, as manifested by at least one of the following repeated assertions
       (a) that he will grow up to become a woman (not merely in role)
       (b) that his penis and testes are disgusting or will disappear
       (c) that it would be better not to have a penis or testes
     (2) preoccupation with female stereotypical activities as manifested by a preference for either cross-dressing or simulating female
     attire, or by a compelling desire to participate in the games and pastimes of girls.
     C. Onset of the disturbance before puberty. ...

The DSM IV broadened the diagnostic criteria for Gender Identity Disorder in children, with the result that children no longer had to state a clear interest in or belief that they are the other sex. Instead it said:

1. In children, the disturbance is manifested by four (or more) of the following:
   1. repeatedly stated desire to be, or insistence that he or she is, the other sex
   2. in boys, preference for cross-dressing or simulating female
      attire; in girls, insistence on wearing only stereotypical masculine
      clothing
   3. strong and persistent preferences for cross-sex roles in make-believe play or persistent fantasies of being the other sex
   4. intense desire to participate in the stereotypical games and pastimes of the other sex
   5. strong preferences for playmates of the other sex
2. In children, the disturbance is manifested by any of the following:
   • in boys, assertion that his penis or testes are disgusting or will disappear
     or assertion that it would be better not to have a penis,
     or aversion toward rough-and-tumble play
     and rejection of male stereotypical toys, games and activities;
   • in girls, rejection of urinating in a sitting position,
     assertion that she has or will grow a penis,
     or assertion that she does not want to grow breasts or menstruate,
     or marked aversion toward normative feminine clothing.
3. The disturbance is not concurrent with a physical intersex condition.
4. The disturbance causes clinically significant distress or
   impairment in social, occupational, or other important areas of functioning.

Just found out about this photo on Flickr cause it's gotten a lot of views in the past few days. Such a great shot of the Hopey hound, makes me miss her more than I already do.

• Getting keys made is something done at the cobbler's, not at hardware stores (we visited 2)
• At 5 or 6 pm, there is nothing slightly resembling dinner available in the local cafés and the restaurants are not open yet.  We will need to adjust to this.
• There's some great fashion here and then, in contrast, some people who seem to actively hate fashion :)
• I love having opportunities to speak French!  Most importantly, everyone is speaking French back to me which is a pleasant surprise.
• Everything here is REALLY EXPENSIVE!  It makes me kind of nervous.  Will need to get out of this neighbourhood and see what it's like in less touristy areas.  We plan to get Velib bikes to explore the city tomorrow if it's not raining.
• I bought a SIM card at the airport for 19 euros and it gives you 5 euros credit which I've already gone through by using data, however there's nothing in their rate sheet about data costs. SO there's some lack of communication here.  
• Also this:

It's NOT a coincidence so many cities are making alternatives to the OFFICIAL "family" Pride parties which rely on corporate sponsorship. Pride went from a march to show we existed to a bloated tourist attraction that requires millions of dollars to survive. Let's stop doing the SAME thing EVERY year, it's lazy. Get freaky on your block, love each other up in the streets, throw parties any day you want. Fuck Pride.

I love us.

After moving to the United States just over six months ago I started driving a car again. Spending a lot of time commuting has given me a whole new view of car culture - California car culture to be precise. Highway 280 running from SF to the Silicon Valley has shown me a whole new world where most cars only contain one person (including my own), are often hybrid or at least manufactured by Toyota, and are generally free of decals. That's probably why I started to notice this phenomenon of family car decals.

I first noticed them in December, often in the form of varying sizes of flip flop shoes in a row on the back window of a vehicle. But lately I've seen more stick figure representations along with the occasional skull version (the goth/rocker family?).

A quick google search turns up an incredible amount of pictures so I'll stop taking pictures of them on my phone now. I've been so curious to know why this is such a contagious sticker trend. I can't help but think that esp. in the recent years of debate over marriage and family caused by gay marriage activism that we are going to see an incredible backlash in the form of "family pride" by people with traditional hetero family units. 99% of the stickers i see depict nuclear families. Some add on a dog after the stick people. This could be because a divorced family and thus spread out family might not have one car to put all its stick figures on...or just that only families who fit a two parent/many kid mold think it's cute to get a sticker version of themselves made.

I'd almost put my obsession with the trend aside when I saw this:

1. Bring their websites over to an open-source CMS like Drupal. Many of the sites are hand-coded php (or god forbid Dreamweaver-created sites) with no administrative back-end and keeping the site's information up to date is a difficult/dangerous task for non-technical staff.


2. Take their FileMaker Pro databases over to MySQL or PostgreSQL so that they are no longer locked in to expensive, proprietary database software that requires additional hosting costs. Three organizations I have worked with are on three different versions of FMP and none of them the latest. Upgrading is painful for them and their hosting costs are ridiculous (especially the ones who are on older versions).

We're ready for a soft release of the first step in our very experimental autolanding system. Experimental meaning: we reserve the right to pull the plug, take it down for tweaks, and some information may be lost when bugs arise.  You can check the if the autoland system is up and running by going to http://bit.ly/autoland_status

This is the Try branch only portion of what will become a system to automate and more easily manage multiple branch landings.  Marc Jessome, our returning Release Engineering intern, and myself have this as a Q1 goal.  There are several issues to be resolved with this system and the link above will keep you appraised of what the goals and known issues are. We will be working hard over the next two months to make this a secure, reliable system for landing patches with minimal developer time spent pulling, pushing, and watching tbpl.  The hope is that it will also become a useful tool for Release Coordinators to track that a fix lands across several branches as needed.  Future features will include a bugzilla extension to securely interact with this system and remove the need for whiteboard tag changes and a RESTful API so the whole process could be initiated through the command line.  We appreciate constructive feedback but please hold off on scope creep suggestions :) 

Here's how it works right now:

1. Attach patches to your bug Note: if you (the attacher) do not have permission to push to Try, get an r+ from someone who does
2. Use this documentation to determine the appropriate whiteboard tag and enter it in the bug so our autolanding poller will pick up on your request
3. The autoland system, which tracks all bugs with autolanding requests, will queue up your patchset and then pull it from the queue, apply the list of patches in your bug (or those in the whiteboard tag) to a clean pull of mozilla-central tip, commit each patch as the patch author, and finally push to try as Autoland User
4. A comment will be posted in your bug with the results (hopefully successful) of the push attempt, and the whiteboard tag will read [autoland-in-queue]
5. After all builds complete, their results get posted back to your bug (just like with the current '--post-to-bugzilla Bug #' flag in trychooser) and the [autoland-in-queue] whiteboard tag will be removed

Last Wednesday David Eaves presented the results of the multi-tiered contributor lifecycle audit (watch the video).  A few points really grabbed my attention and as someone with a background in arts & education non-profits I feel the need to share my experiences alongside my reactions to this talk.

David pointed out that as we are growing, we can hire people to solve problems, so what exactly do we need volunteers for? Survey results showed that contributors often don't feel their contributions had much impact on the project and that as our paid staff pool grows in size, there is less clarity about what exactly a volunteer's importance is to the critical path of Mozilla's mission.  I wish we had this data prior to the 1+ year push to releasing Firefox 4.  My hand-waving hypothesis would be that as we were cramming to get a product out the door we forgot to be leaders of volunteers and instead unconsciously pushed them aside so that things could get done on a schedule.  It was a stressful time, but now that we've moved on to regular, rapid releases perhaps we paid staff can all take a step back and really assess how we incorporate the work of volunteers into our individual areas.

For many Augusts I have worked at a women's music festival in the woods of Michigan and at that festival there is a kitchen that has pumped out 3 vegetarian meals a day for 5 days to 4000-8000 attendees depending on the year.  This festival relies on a core group of 'workers' who are in fact volunteers but let's pretend that group of 500-600 people is like the paid staff of Mozilla.  The main kitchen work crew gets about 30 workers to run the kitchen.  You might think to yourself "but 30 people cannot produce enough food for 4000-8000 women" and you'd be very right.  The way it works is that all attendees of the festival are asked to do two 4 hour workshifts during the week they attend the festival.  The majority of workshifts center around the main kitchen and creating the meals which range from burrito night to pasta putanesca to nutloaf (a vegetarian version of meatloaf). All these meals involve preparation of pounds upon pounds of vegetables as well as cooking of pasta, beans, sauce.  Did I mention this was all in the woods, over a massive firepit?  Yup, so 30 women are in charge of making that entire process work and they do so by wrangling hundreds of volunteers per day into shifts around each meal and constantly leading and dividing up the work so it can be done by many hands yet results in one huge meal - 3 times a day!

So let's go back to people who are volunteering not feeling clear about how Mozilla works and whether their time and effort has impact.  How can we make sure that the smallest task makes that person feel like they've contributed?  Some areas of Mozilla do this very well to name a few; AMO, SUMO, QA, and Personas. These teams manage tons of volunteers and have tasks with measurable outcomes (tests run, filing bugs, approving an add-on, answering a question in the knowledge base, shrinking the queue of pending Persona submissions) and sometimes they can use scoreboards or themed days to get volunteers mildly competitive for the respect of their peers and accomplish larger goals in a short burst. I'd encourage people interested in having volunteers participate in their team's work think about how to make sure their volunteers have tools to measure their impact from the get-go.  In Release Engineering I would measure the number of bugs that we have yet to fix, many of them labelled "simple" or "old".  If I had volunteers doing RelEng work I could keep track of their progress and post reports (as blog posts) of who fixed what when and how as the number of bugs shrank.

Another interesting result from the survey: older folks (34-55!) aren't on-ramping as much as younger ones. At first I wondered how much of this was about access to the muscle memory of being a student.  I think it's fair to assume that many students/youth can have a lot more time to contribute to projects like Mozilla as certain adult responsibilities may not be required of them yet. Over the past week though, I have started to visualize another take on this. In the arts & social justice organizations I have been involved with there have been plenty of adult volunteers but those organizations have a different need for volunteers. The music festival I mentioned would not happen if it wasn't for volunteers.  The fact that the volunteers want the community of the festival to exist for them every year becomes the carrot drawing women of all ages to come to the woods of Michigan and build a music festival every year.  People quit jobs, take unpaid leave, and make plenty of other sacrifices of their time to participate in creating this community. The thanks for this 2-4 weeks of donated work is an amazing live/work experience camping with 5000 women on private land, having workshops, parties, and dances all in a very natural, safe, and ad-free environment and watching incredible performances all day and night for 5 days. 

In a different example, let's look at a the Toronto International Film Festival.  Volunteers have to make it through the rigorous screening and application process in order to 'get' to volunteer for the festival. They are rewarded with behind-the-scenes access to the festival, sometimes a quick run in with a movie star, and free tickets to festival screenings.  The festival shows entirely world-premiere films so this is a huge deal for a volunteer.  Several films will see theatrical releases after the festival but seeing the premiere, often with the star in attendance and with a director Q&A post-screening really sweetens the experience. The volunteers also get thanked before every screening with a cute trailer from the sponsor for the volunteer program and there's always a fantastic party post-festival as the final thank you. 

At Mozilla we do thank our volunteers with tshirts and sometimes bringing them to summits, MozCamps, or other parties. For older volunteers though, I wonder if that's enough.  What does it take to get someone in the 34-55 range to donate their time?  I'm really interested in this one since I fall in that demographic as well.  For me, I need the time donated to do at least one of the following things:

• be social, meeting new people in the community I chose to volunteer in is a big part of why I'd do it in the first place
• provide a networking opportunity (similar to above, but might apply to folks on the job market a bit more accurately)
• get me free access to an event I wouldn't attend if it wasn't
• be something my friends are also doing so we are visiting with each other while doing something interesting
• be for a very good cause so I feel good just helping that cause regardless of the tasks I perform

Last Thursday night about 8 women arrived at Noisebridge to learn how to contribute to Wikipedia.  Several things led to this gathering:

• An article in the New York Times back in October drew attention to the lack of women contributors to the Wikipedia knowledge base and that got me thinking.  
• Having organized other spontaneous "women get together and learn stuff" events I figured I could take the same approach to Wikipedia contributing, get some women together to create accounts, generate content, learn how to stop vandalism and see what would stick.  
• Recent participation in activism around the Occupy Wall Street movement also inspired me to try and reach out to communities I am in who are not as technical, to encourage people to come first with knowledge and interest in topics Wikipedia could benefit from and let the tech come second. 
• A month ago Elsa and I were talking casually about all the the above mentioned things and we decided to just go for it and pick a date, throw it up on the Noisebridge (local SF hackerspace) calendar, and see what we could make happen.

• Having a "new to wikipedia" moniker next to their nickname for the first N activities on the site (we have this on our Mozilla bugzilla) so that hopefully older and wiser participants would be extra nice to them
• Find a way to make some of the simpler tasks that help Wikipedia (typos, reverting vandalism, categorizing articles) into a game that a new arrival could play that would start easy and then move more toward the real-life workflow of working on Wikipedia - as a way to warm them to the UI
• Encourage newcomer to write a straight-up article and have a place for these things to be dumped for inpection/linkage/categorization and otherwise Wikipedia-fying the knowledge dump.  My partner is an English professor and can certainly write good content for Wikipedia but everything about the site is intimidating. There should be a page where she could copy/paste or upload a document of her article and then let people who know wiki syntax and the other requirements an article needs come along and finish it up
• Make it way easier to find the "adopt a user" program that I hear exists but no one would know to find that from the Wikipedia home page

We’re proud of what we’ve accomplished already.  Since our founding in
early 2011, we helped over 30 conferences and organizations adopt an
anti-harassment policy, organized the first AdaCamp unconference,
provided free consulting on high-profile sexist incidents, wrote and
taught two workshops on supporting women in open tech/culture, and ran
two surveys, among other things.

http://adainitiative.org/what-we-do/

We need your help to achieve our upcoming goals.  The Ada Initiative
is funded entirely by donations.  Without your financial support, the
Ada Initiative will have to shut down in early 2012.

http://supportada.org/donate

Your donations will fund upcoming projects like: Ada’s Advice, a
comprehensive guide to resources for helping women in open
tech/culture, Ada’s Careers, a career development community, and First
Patch Week, where we help women create and submit their first open
source patch.  You can learn more about how the Ada Initiative is
organized and operated on our web site and blog:

http://adainitiative.org

Whether or not you can donate yourself, you can help us by spreading
the word about our fundraising drive.  Please tell your friends about
our important work.  Email, blog, add our donation button to your web
site, and tweet.  Here’s how:

http://adainitiative.org/support-us/spread-the-word/

You don’t have to stand on the sidelines any longer.  You can help
women in open technology and culture, starting today.

Ok, I'm a little biased - full disclosure: I work for Mozilla.  But even if I didn't I suspect I'd be impressed with the amount of amazing innovation and hustle that Mozilla's community puts out towards making the open web more accessible to everyone.  Recent projects like Popcorn and Butter are changing the way we work with video on the web. Hackasaurus is reaching out to kids, getting them to move beyond consuming the web (read-only mode) to being able to build and design their own web experience (read/write).  Addons SDK, Open Web Apps, Browser ID, the list goes on and on and I'd better stop now or I'll lose you before getting to the good stuff.

Mozilla may be a huge brand but we're actually a relatively small group of people doing this work all around the world.  Which is why we now have WebFWD, a program to help innovators of the open web get a chance to hook in to the resources of Mozilla (space, mentors, public reach, food and housing, and more) to help bring their products to the world.  With this rolling program of projects Mozilla can be a driving force in getting more open web to the people who need them.

Right now we need a visionary and hard working Program Manager to become the leader of this movement.  I'm attaching the posting below, get in touch with p at mozilla dot com with your resume for consideration.

/// WebFWD - Program Manager

Mozilla, the organization behind the Firefox Web browser, is looking for 
an all-star to join our new accelerator/incubator program WebFWD 
(http://webfwd.org) which aims to do for the open Web what organizations 
such as Y Combinator, TechStars and Seedcamp have done for startups.

As the Program Manager of WebFWD you are charged with leading the 
overall program - from designing and managing the curriculum, supporting 
the selected teams locally as well as globally, working with our 
ever-growing list of mentors and partners to organizing events.

If you're passionate about the Web, want to help people build amazing 
products and are willing to roll-up your sleeves, then this position is 
for you.

Primary responsibilities:
* Design and manage the curriculum for both the Fellow program as well 
as the Bootcamp
* Work with and support teams in the program (both locally and remote)
* Work with our mentors and partners
* Coordinate community and press outreach on a worldwide basis
* Create and run events (locally and remote)

Requirements:
* Excellent written and verbal communication skills
* Experience with organizing and running events
* Experience working with startups, entrepreneurs, venture capital and 
incubators / accelerators a huge plus
* Proven ability to work independently and in cross-functional teams
* Familiarity with Web technologies
* Passionate about helping people and solving problems
* Enjoys learning and teaching others
* Works effectively in a fast-paced, start-up environment
* 3-5 years of relevant job experience
* BA/BS, or equivalent experience

The TrySyntax helper and TryChooser wiki docs have both been updated to reflect the new option when pushing to try where you can now ask to have your complete summary of results (and a link to the tbpl page for your revision) posted as a comment to the bug on completion.  Here's a live example to check out:

As I write this I am working from Paris and our team timezone spread looks like this:

•  Rangoria, New Zealand: UTC (+12)
•  Bucharest, Romania: UTC (+3)
•  Istanbul, Turkey: UTC (+3)
•  Paris, France: UTC (+2) <--- ME!
•  Ottawa, ON: UTC (-4)
•  Toronto, ON: UTC (-4)
•  Philadelphia, PN: UTC (-4)
•  Clifton Park, NY: UTC (-4)
•  Chicago, IL: UTC (-5)
•  San Francisco, CA: UTC (-7)
•  Mountain View, CA: UTC (-7)

* We meet once per week as a whole group on Mondays. This starts the week off with a status update on our major projects and also a chance for individuals to speak up about anything they're working on that they'd like people to be aware of.

* We are always having conversations in IRC amongst ourselves and with others in several channels. We use #mozbuild as a backchannel for our inter-team discussion, #build for access to a larger group of fellow Mozillians (like philor, Kairo, and ted for example, who often need to liaise with us), #developers is also a place we frequent and then there are some IT/mobile/QA/release-specific channels we hang out in as needed. I think this helps us have a presence in many areas of engineering/dev/IT and even with some of the non-technical teams at Mozilla where inter-team communication needs to happen. It keeps us in the loop on what various teams are up to and also provides the IRC equivalent of being able to overhear water-cooler chat and participate as well.

* We keep wiki pages for most everything. From "how-to" pages for our own release process, automation details, and project planning all the way to pages for outside-releng folks like the Try Syntax. While I find wikis frustrating the minute the information is out of date, the fact that I can update them and find them in my awesomebar quickly when I need them is very valuable to me.

* We email our group with important notices and changes to how things are done. There are not often times when someone will say "Oh I didn't know about that" and the response is "It came up in the hallway when I was talking with so-and-so". More often than not, the person driving a particular upgrade or change to current practices will send out an email to the group with details of : a) what the change is b) what it means going forward c) how the message has been disseminated to a wider audience (if needed) and finally d) where the wiki pages (and bugs, if needed for reference) can be found. This allows any of us to find the information N time units later when the change actually comes up in your daily work and you're wondering "What was I supposed to do when trying to use the new X again?"

* We all meet up face to face approximately once per quarter. Twice a year for Releng work weeks and twice a year at Mozilla all-hands/summit gatherings. We take these as opportunities to discuss larger topics with lots of brainstorming, whiteboard scribbling, and animated opinion-sharing. Notes from meetings like this turn into wiki pages (often during the meeting itself) and those can become specs for projects/bugs to carry the work that needs doing to the next level.

* Not having meetings in large groups in MV (except at all-hands). Instead, put small groups of people in various rooms around the building so that "we are all remote" is a reality for everyone so that the clarity of the communication channels are taken seriously. This means we all become just as invested in the quality of audio/video feeds, using tools like Etherpad for public collaboration, and advocating best practices for the speakers/presenters as those who are not in MV. I bet we'd see an increase in contributions to new tools & meeting practices if we were all experiencing meetings remotely on a regular basis.

* Rotate the hosting of the Monday meeting so that over a series of Mondays it would be run from various remote Mozilla offices and this would mean that it moves in time (which could be scheduled in advance) but it also means that all offices get a chance to feel special and be the center of attention. We'll have an opportunity to get to know our co-workers from other offices better as they present the meeting and I even imagine some friendly competition could develop for who can run the most energetic and engaging meeting.

Ehsan's blog post wishing for assisted landings on mozilla-central started a lot of people talking about this being a very desirable and useful tool for developers, where they could set a flag in Bugzilla and then be free to do other work until the results of their push were posted back to the bug. As part of enhancing the Tryserver I was already working on a way for users to signify in their try-syntax that the results of the push should go to the bug and these two ideas started to fuse into a dreamworld where someone could attach a patch to Bugzilla and have it be tried and pushed to trunk all with some magical bot automation.

After doing a very short survey of developers and their try usage I have observed that there are two very different stakeholders here and both of them need separate-but-related tools:

• Adding more Try syntax options:
• include list of the bug(s) that you would like your try results posted to (however many make for a complete run on your push, this can be one linux build or a complete ~186 builder try: -a buildset) 
• turn off email notifications
• Adding functionality to the self-serve api view for a revision (eg: https://build.mozilla.org/buildapi/self-serve/try/rev/de8ea75bc48e) that will better show your results for that push and provide a button which will post the patch(es) to a specified bug
• Auto-landing from a bug in Bugzilla using the [autoland-try] whiteboard tag where any attached patches which are not obsolete, and have nothing set for 'r' are applied to the current tip of mozilla-central, pushed to try and those results are returned to a comment in the bug

• Crawl Bugzilla for bugs where [autoland-$branchname] is in the whiteboard and automatically push to tip of named branch, get the results, and return them to a comment in the bug (stripping out the whiteboard tag on completion)
• bot will grab all non-obsolete, r+ patches (if $branchname != 'try') 
• interdependent bugs will not be handled in this first swipe at a working system
• pushes will have autoland-$bugnumber as the reason for the build in schedulerdb so that the results can be watched for, aggregated, and reposted to the bug on completion
• Watch results coming back for one or two oranges (we can set a threshold) and re-triggers those, watching for the second set of results - to attempt catching intermittent oranges
• Backout patches where even with a rebuild on an orange, there still remain orange results
• LDAP authentication checking for bugzilla patch author -> hg commit permissions and being able to ensure that only people with the right credentials can trigger automatic landings. This may mean checking the reviewer too before allowing a patch to be applied & pushed.

The first Bay Area PyStar event has come and gone. I'm finally getting a moment to regroup and ponder all the trial and error of being the organizer of this event as well as having time to look at some of the statistics we gathered. Just from an organizing perspective here are a few items I'd like to share about the process.

Things to do differently next time:
* When creating the Eventbrite event, add questions like "What level do you want to learn at?" "Meat or Vegetarian?" "Operating System?" to the registration so there's no need to send out blanket emails to attendees to try and get that information after the sign up.
* Only do one day workshop instead of Friday night installation and Saturday workshop. I think that for many people the setup could have been done in the first hour and the rest of the day been spent learning instead of having a night session that only is needed by a handful of people.
* Have the teachers/assistants already assigned to a particular level of instruction - prepare topics, tutorial materials, and class size ahead of time so that on the day of the workshop there might only be a handful of late arrivals to place and the other attendees will already be set up in the right learning level as requested in the sign up. 

Things that really worked this time:
* Eventbrite! They have amazing tools, stats, emailing options, charts, and also a way to see where your sign ups come from which showed us that we got a TON of views from Tweets which apparently was an impressive number (I am told by one of our attendees who is an Eventbrite employee)
* Mozilla! By sponsoring the event - providing the space and food - being able to let people/groups spread out and work in our various conference rooms as well as having lunch on site was very much appreciated by attendees (and of course by me!)
* CodeChix!  This peninsula-based group of women coders accounted for 30% of our attendance and also netted some teacher/assistants for the workshop. CodeChix co-sponsored the event and helped get word out as well

Attendance
There was something odd happening with the Eventbrite signups. In a couple of short bursts, a ton of tickets were being snatched up by names that seemed slightly suspicious. Now the event has passed and I've checked in all the attendees as well as accounted for the no-shows (almost all of whom took a moment to send in their regrets so the tickets could be freed up for another person - very sweet!). It looks to me like about 40% of our attendees were fake accounts. Julie (who works at Eventbrite) and I took a look at the numbers and she's kindly offered to look into it further to see if there is indeed something fishy happening. All that aside, we had 47 people! That feels like great attendance to a first workshop, on a Saturday, in Mountain View.

Alternate title ideas: "It's not all s/Tryserver/Try"  or "What I should have done, and didn't"

I bet you get the point by now. Today I caused a fairly lengthy, unnecessary downtime on Try.  Now that I'm writing this, things are under control again and there's a few small niggly bits left but nothing that will keep me up at night.

It all started with a bug about graphserver posts from tests not getting through because they were looking for MozillaTry (the tinderbox name for Try) but instead the graphserver only knew about Tryserver (the branch name for Try) and nothing was using Try (except the repo for Try) which is what it ought to have been doing in the first place.

Now that I've been adding a lot of project branches in a short amount of time, certain things have become more streamlined and so I felt that the best option was to go through and rename Tryserver/MozillaTry to Try everywhere so that from the repo going forward, everything was the same. This has been working extremely well for our project branches and helps make setup a snap.

Here's where it gets all broken. I approached this bug with a quick swipe at this problem was superficial and ended up causing some preventable burning.  I shall now list for you (and future me) what I did and what I should have done:

Did:

• hg rename on configs for desktop
• branch configs for s/tryserver/try
• updated graphserver branch name to Try
• a quick downtime window from 10am - 12pm in order to prevent builds from getting split into two different upload dirs

• hg rename on configs for mobile
• grep of buildbotcustom for "tryserver" as we have special casing for it in several files
• log uploader and post_upload scripts to make sure everything about the try build was going to the right place
• updated the dir permissions on ftp for the new upload location and ensure that the archive is on nfs mount
• edited cronjobs on staging to catch the new try builds
• updated graphserver machines table for each try platform's builder name
• more notice for downtime, with a 4 hour window that would have allowed a test push to make sure everything was wired up correctly  
• updated the treeclosure hook to include the new tinderbox page

1. Staging is not to be underestimated even for just renaming things that are already working
2. Taking the time to search with grep/mxr and find the terms you are replacing before starting the upgrade in production will help find wiring you might have overlooked in your preparations
3. Prepare more thoroughly and have a clear idea of the env. you started in and what it will take to have that env. back when you're done. Leaving dangly bits is not ideal.

Dear BBC,

Today on the front page of your technology section you said that downloads for Firefox 4 have been lower than they were for Firefox 3 and that:

The lower figure may be explained by the widespread availability of pre-release versions of Firefox 4 in the months ahead of its launch.

• We put out the RC and picked up users from outside of our usual beta testing pool in order to give our final candidate some solid tire kicking
• Firefox 4 went live but our users on 3.5 and 3.6 are not offered the update automatically yet, they must "Check for updates" in order to be asked if they want to upgrade to Firefox 4 
• Once we have more coverage of the new release for a couple of weeks and are even more confident that we've got an amazing browser out there we will turn on the Major Update notification which will offer our 400+ million users the chance to come on up and experience the next level of the web

Lately I've been working on a a script which can check your try syntax for a bug number and a setting asking for --post-to-bugzilla.  If you've provided both, your try server results can be posted directly to the bug.  This is just part of a larger project to have patches submitted on a bug get automatically tried out, results posted, and at some point down the road they could even be pushed to trunk after a successful try run so "look Ma! No hands".

Today I have a script running in staging, polling for completed try runs and doing dry runs of posting to bugzilla in log format only so I can keep an eye out for unusual output.  Already this has shown me a couple of bugs to sort out, and I anticipate having them ironed out very soon.  However, before this lands I would like to get some feedback/ideas/suggestions on what the output to the bug should look like and there could be a couple of options even, with a setting in your try syntax.

In my early testing I posted to our landfill bugzilla and here's what a couple of results looked like:

Try run for $revision with the following comment:
$try_syntax line
S:# W:# F:# (results total) builds complete from N total requests
S:# W:# F:# (results total) tests complete from N total requests
For more information please see http://tbpl.mozilla.org/?tree=MozillaTry&rev=$revision

• Bug 617321 tracks adding two new try buildbot master instances to our other buildbot-masters in the Santa Clara colo.  This gives us flexibility to have rolling downtimes on try (as we already have on the other masters) where we can update things behind the scenes and it also helps by adding redundancy to the try automation in case of a colo outage.
• Bug 580346 is almost done and it adds xserves to try which gives us some faster macosx building power, that along with about 40 ix builders for win/linux builds will crank out more try builds faster.
• Bug 594236 is key to getting TryChooser syntax turned on as a default.  With an interactive hg prompt on push to try, you should be able to select what you want and/or have your syntax validated.  Khuey started something to do this and if anyone is up for taking it to the next level before I can get around to it, please please do.

• Bug 430942 is what I am actively working on today and the rest of this week, I'm about to have a second draft ready for review and I expect you can watch for this to land in the next few weeks. With or without try syntax, you will be able to specify the bug number in your push comment and have the results of your try run posted as a comment on that bug.  Hopefully this will help out development in letting people know where something is at if you are away when the results come in. It's also part of our old bug (pre-2010) smack down goal so finishing it will be one more step toward that carried-over goal being met.
• Bug 615705 is tracking a few more tweaks to the try syntax that will give users more flexibility in the syntax and choice about what to build.
• Bug 421895 is another old bug and Chris Atlee is close to getting it up for poking at. It provides a way for users to cancel their own try build requests without having to ping RelEng.
• Bug 621681 addresses having better threading/headers since the current headers only help with threading for some clients. When I first wrote it I was testing with Thunderbird, where it works as intended but apparently Gmail and other clients need some help.