Tagged: projects

Ascend Project Kickoff

Last year I approached Debbie Cohen, our C-level People person, and made a proposal.  With all these Hacker School/Dev Boot Camp/Hackbright accelerator programs popping up, I had an idea to create an open source version and specifically target participants who come from underemployed, LGBTQ, Latin@, and African American populations – aka: people who are terribly underrepresented in tech but also very much more so in Open Source. The idea was that instead of people paying to come learn to become developers in the capitalist, Startup-focused, feeding-frenzy the Silicon Valley promotes we could instead seed other towns, other communities with open source and create an in-depth technical contribution training program that more mirrored the experience I had with Dave Humphrey at Seneca College. Imagine my surprise when Debbie clearly, and without hesitation said to me “Great idea! Do it!”.  I’ve been building up to something that is more sizeable through running local events, hack meetups, participating in community building in several ways so I saw this proposal as the next step for me, as an organizer.  This time I’m going to do something that is bigger than what I could do alone. I will have Christie Koehler working with me as well as several community building team members in advising and mentoring roles.

The populations I want us to reach out to have resulted in certain adjustments to the typical setup of those for-profit accelerators which I see as being key to the potential success of our cohorts. Attendees in the Ascend Project will benefit from taking this course in the following ways, which are intended to remove many barriers to participation in Open Source:

  •  a $50 per day honorarium will be provided to encourage regular attendance and help ensure participants can afford to focus on being present to learn & develop
  • laptops will be provided to use during the course and upon completion, graduates will get to keep theirs
  • food (breakfast and lunch) will be provided every day
  • where needed, childcare stipends are available to participants who need additional care in order to put in the time this course will request of them
  • transit passes for the whole 6 weeks

The purpose here is to not only acknowledge that we know we’re missing people in our open source communities but that we’re willing to put our money and time where our mouths are to go and explicitly invite people who like to solve problems to come and see what it is like to get to just focus on learning, developing, fixing a bug, getting hooked, being a part of a bigger community with a mission for global good.  I see this as a solid way to counter the manner in which many of these populations are pushed away from participation in computer science and open source contributions.

We can’t expect every person who might be a strong, longtime, and impactful contributor to Open Source to find us based on passion alone.  That leaves all the systemic issues in society to decide for us who gets here.  If we can remove some barriers and provide an environment where participants in a program get a chance to feel confident, trusted, strong, and *wanted* then we can see how that might blossom their abilities to learn and contribute to an open source project that has a ton of pathways for potential input and impact.

The project is currently still in the kickoff phase so this is the first public post.  Mostly I’m braindumping, trying to work backwards from September when the course will start, and getting my head around who will do what so we get everything ready in time.  I’ve got a budget for the first pilot, which will take place in Portland, OR in the Fall of 2014, and it’s almost approved.  Next up I will be designing the curriculum while Christie works on partnerships locally in preparation for our call for applications.  We’ll be doing our best to reach far outside the typical degrees of separation to get word out and to attract applicants.  I’ll be in Portland next week to meet with local orgs and gather information on where we can promote the project.

Applicants will go through several steps before we whittle down to our final 20.  There will be an expectation that they can complete the highest level of a free, online Javascript course and the Mozilla PDX office will hold drop ins with computers available to help applicants have the time to do this with the right equipment and a mentor or two nearby.  Following that stage, we’ll ask for an essay or video that briefly describes a ‘hard’ problem the person had to solve, if they were successful what worked and if not what didn’t.  Staying away from specific, alienating technology language seems key here. We need problem solvers and self-starters, not people who know syntax (yet).  That group will then be the pool from which the final participants will be selected from, with specific ratio targets for populations that I mentioned earlier.

The first session, as a pilot, will have certain ‘training wheels’ on it. Mozilla has a great space in Portland.  Portland has a wonderfully large open source community I fully expect to tap into for networking and partnerships.  We’ll be using this first pilot as a way to test the participant selection process and the curriculum itself.  I really want to be setting people up for success.  This is measured by committing at least one patch to production code (in any area of Firefox) before the end of the course.  Our first course will focus on Mozmill automated testing because we can get our participants to that level of success with independently-written JS tests for several of the Firefox products.

Following Portland we’ll be reviewing, updating, improving, and then taking the next pilot to New Orleans in January of 2015 where we can test “what happens if we don’t have an office, a large community already in place?” with our tightened up selection process and curriculum.  The two pilots should give us lots to go on for how to scale up an initiative like this going forward and hopefully it can become something that happens more frequently, with more teachers, and in many more places (like in some of our Firefox OS launch markets).

That’s the gist for now.  I’ll be posting more frequently as we hit milestones in the project and also am happy to take people up on offers to review curriculum.

Why I was part of creating a thing called TransTech(SF)

Last night I helped hold the third local meetup of trans and genderqueer people who are interested in getting together to hack on our projects. This is the third event since the amazing Trans*H4CK  Hackathon (the first one of its kind!) that took place in October 2013.

When I heard through the grapevine that there was going to be a trans-focused, trans-organized, local hackathon I was beside myself.  Finally I would get the combination of identity and technology in one space that I have been dreaming of since going back to school as a mature student in 2004-5 in order to get a degree in Software Development.  My lofty goals in going back to school can easily be summarized in two ways: 1. I wanted to get a better job than being a brunch chef or a non-profit artist-run center, contract employee with no job security or dental benefits and 2. I hoped that whatever I could learn about technology and software would become tools I could bring back to my queer/trans/genderqueer/arts community and help anyone who wanted it at whatever level they ask for.  This has come to mean hosting websites for people, helping build websites for people and small orgs, and also doing some random consulting. It has also led, funny enough, to a certain amount of fixing people’s computers.  That’s nothing I learned in school, it’s just something I seem to have the right combination of lucky and chutzpah to try — ratio of success lies at about 85-90% so far (some things are unfixable, by me at least).

Anyway, I got into tech and got through a grueling 4 years of school with all its associated stresses.  No need to go into details because I finished that thing AND I got a pretty amazing job right out the gate.  Health benefits (specifically the much-needed dental)?  Check.  Ability to help my communities with tech stuff?  Yes….ish.

Turns out it’s not that easy to still be people’s go-to for tech help when you start working more-than-fulltime at a fast-paced company. Also when you move across the country from the majority of your closest friends and aquaintance community.  I made that decision though because I wanted to take the opportunity that existed for me to come here, to SF, and be in the heart of it all.  Little did I know at the time I was walking on stage at a very precarious time (that’s a whole other post).

Skip forward.  I’m lucky enough to have one woman (self-identified to me as a feminist on our first meeting) on my team of 8 people.  So I think tech is pretty awesome. Then she leaves, goes to another team.  Then I go to my first PyCon and swim in a sea of homogenous men I don’t know.  Then I meet a handful of really exciting people who put the words “Queer” and “Tech” on a scrap of paper for a DIY session in the basement of that hotel in Atlanta, 2009.  That is one of the *big* moments.  It’s when I started, with that group of people, to promote teaching Python to women. Based on the success of RailsBridge‘s workshops teaching Ruby on Rails to women (I went to one, Ruby and Rails are not my thing for now) and also the Boston Python Workshop which did a lot of the groundwork for adapting the RailsBridge-style weekend material to a Python version, I ended up starting PyStar with a few people. Our goal was similar:  make it possible for more women to feel comfortable learning Python in a non alpha-male space.  We had a few workshops in SF and Mountain View (Mozilla office space was easy to get and use for weekend workshops). There were groups creating workshops in Philadelphia (still, to this day, the most active city for this project) and in Minneapolis.  I even threw one together in Paris for a night when I was living there for 3 weeks and working from the Paris Mozilla office.

I’m sharing this with you, reader, because this is the backdrop for what comes next.  For me, teaching women to code was…OK.  Don’t get me wrong – it’s important work and I’m glad it’s happening.  For me though, I still felt kind of lonely.  Since the majority of attendees were middle/upper class, young, heterosexual women I wasn’t really connecting on the levels that I do with people who share other similar identities and life experiences with me.  Or at least ones I am more familiar with, if not my own.

I got a bit disheartened by organizing events that I no longer felt I truly connected with and I took some time to try and figure out how to best spend my time and how to be the activist I wanted to be.  Enter GeekFeminism, having several of the people I met through that hired on at Mozilla, PyCon drastically improving its ratio of women attendees (speakers, still being improved), and meeting Leanne.  Over the past couple of years, again keeping it short, I’ve managed to go to conferences and meet lots of people and dream big with them. The LGBT lunches at Grace Hopper have been fascinating.  Getting to attend AdaCamp – huge boost.  Finding people and connecting with them on all the things that are big problems we want to be a part of solving — the one is often comes down to is “How do we get more diversity in tech?”.

At Mozilla I end up making that a second full-time job that is not what I am paid to do (working on that).  Instead I got discretionary funding that I could use to help leverage women in open source which eventually grew into supporting anything with diverse populations that were not prominent or numerically well-represented in open source.  This looked like me being able to offer up the Mozilla office(s) if and when I could be there to hold the space.  It looked like being able to sponsor a variety of events with amounts less than $2k who were promoting, retaining, or otherwise engaging people in tech & open source more specifically.

One of the events I ended up directing money towards was Trans*H4CK because, as I mentioned at the start – I was so frickin’ excited that this was going to happen and I wanted to help it happen.  I reached out to Kortney and offered money, asked if (while I was planning to attend regardless) I could talk for 5 minutes about open source. I did that.  I went and talked and gave my, now usual, talk about why open source is important (think: View Source on webpages and how you might have benefited from being able to do that).  Then I hacked on stuff and met people and generally soaked up what it felt like to be in a space where I felt seen, whole, and just surrounded by people who were also being seen.  We exist, in numbers more than the one or two at your day job! What a fun weekend.

Then I wondered – why just one weekend?  This was in the Bay Area and while a handful of people traveled to the event most were local.  In the style of user groups and meetups, why not continue to have a monthly get-together of this particular blend of nerdgeektransgenderqueer fabulousness?  I proposed this to Kortney, offered up the Mozilla SF space to hold it, got food for the attendees, and we had one in November that was probably attended by about 20 people.  Pretty sweet.  There was a lot more socializing than actual hacking but that happens when people are still so new to getting to be around each other.  With the success of that, I wanted to hold more but I think the holiday period got in the way so the next one I helped put on, this time at the Double Union maker space, was February 18th, 2014.  It being closer to my house and not at the office I rarely go to anyway was awesome, btw. Also I bought snacks with my own money to bring. That night I thought: we need a regular night – say, the third Tuesday of every month, so that it can be something people just *know* is on and can show up to. No need for invites, mailouts, or headcount – keep it simple. I proposed this to the people at the meetup, and thought this was generally agreed upon.

With that in mind, and with a pretty busy schedule coming up, I wanted to get the March date on the Double Union calendar sooner rather than later so a couple of weeks ago I reached out to the membership list asking if the Tuesday night circuit class would be up for sharing the space with another trans hacking night (as that was the best date for me, as the organizer).  They were open to it and all seemed fine but another email thread started up about whether or not the trans hacking nights would be trans-only or not (if they should, even).  This is something, btw, that the TransTech community participants will be chatting more about so as to determine what guidelines and priorities to have when choosing space or setting up meetings. In that thread Kortney expressed concern about not being able to make the date and I said that I was trying to set up the every-third-Tuesday nights, as discussed at the February meeting.  No further response came and I went ahead with booking it (circuit group moved to another night to give us the whole space, thanks!) and setting up an invite.  Double Union still doesn’t publicize their address so the invite was needed to have a way to reach people who said they would attend.  My goal was to use this next meetup to set up open communication tools that could be used by any member of this nascent “we get together and hack on stuff with other trans/genderqueer people” community.  So we did that.

Last night I was at Double Union with some others and I set up a mailing list, a wiki, and IRC channel, and a Twitter account.  I shared all the admin/login details with the others because this isn’t *my* thing. This is, to the best of my knowledge and experience in open source, how we start communities that are as free of bottlenecks on getting things done as possible.  Then I put that information out there.  The goals, again, are to have spaces where trans and genderqueer people who are in technology (or want to learn to be) can meetup to work on their projects or even work on each other’s projects.  I hope we’ll also get to work on projects that help our communities, for example I’m trying to figure out how to help Homomobiles get an app as it drives me nuts to see people using Uber and Lyft when we have this opportunity to put even a sliver of our collective queer and trans money back to a queer and trans organization and help grow it.

All that to say:  There’s always room for lots of ways to bring people together. This is my expression of how I do it.  Mozilla, while being my employer, does not dictate what I do with my spare time and yet I am fortunate in being able to book our office space(s) when available for events.

I’m being told on Facebook and Twitter that this is stealing, that I’m stepping on Kortney’s toes and please believe me, I tried to do everything I could to avoid that. I intentionally sought another name out of respect for the way that I see Kortney branding and promoting Trans*H4CK and how he is doing great things with that.  I see TransCode (teaching coding), Trans*H4CK (hackathons and speaker series), and then TransTech (local community building, mentor/mentee finding, getting things done in a room with people you have that certain connection with) as all being part of the building blocks for continuing a trajectory of making and taking up space in technology for those of us who are outsiders, underrepresented, or just plain want to put our efforts into working with other social justice activists in building trans & genderqueer focused space.

If you’re in the Bay Area and want to know about meetups, be part of shaping this community, or otherwise lurk about to see what might grab your interest down the road then please follow us on Twitter and/or join our mailing list: https://mailman-mail5.webfaction.com/listinfo/transtech-discuss

Let’s support each other in always leveling up.

 

 

 

 

 

Women Hacking Glass – First SF community meetup

I’ve created an event for the first meeting of Women Hacking Glass in SF at the Mozilla public space.

Since I posted in G+ a few weeks ago things got busy and I didn’t have time to lean on Google like I’d planned to ask for hardware but then a pair of Glass practically fell in my lap when a coworker decided he didn’t want to be an Explorer any more so I wrangled a ‘donation’ to get his Glass in order to use them for community hacking with other women in the Bay Area.  I’m curious to see how the first meetup goes – what will we be able to create?  What kinds of feedback will we provide to the GDK developers who are working on the first version of a release?  What kinds of barriers will we hit with Mirror API?  I look forward to learning about everyone’s hopes and dreams for this exciting hardware and finding ways to hack our way to making them a reality.

Copy from the event invite:

Are you interested in learning how to make apps for Google Glass?  Don’t have the access to the hardware?

Come out to Mozilla SF and meet with other Glass Hacking gals to experiment with Android Studio, creating simple apps, getting access to Mirror API, and trying out your hacks on an actual pair of Glass that will be made available during WHG meetups for testing on.  Since there are very few people out there with the hardware, and few of those early adopter/explorers are women let’s work together to increase the numbers of women getting in on the ground floor for development (as well as being able to provide feedback to Google GDK developers) on this revolutionary new hardware.

There is a small (non-refundable) fee to prevent no-shows from taking up space – all money generated from this event will be donated to Mozilla Foundation via http://www.mozilla.org/donate

Prepare ahead of time:

* Have a google account

* Read https://developers.google.com/glass/quickstart/index and do as much of the pre-installation of tools/IDE that you can

* Think about your first app and what you want to learn to build

* Dream big, show up

For people who are interested in applying pressure to Google and showing them there are women interested in developing for Glass (the current Glass Developers group is easily 95% male) – go to http://www.google.com/glass/start/how-to-get-one/ and submit your request anyway, even though they say the waitlist is full.  My coworker can’t be the only person returning his pair and I trust Google will open more spots when they see a lot of interest.

Mozilla’s got projects for GNOME OPW Summer 2013

We’ve got 2 projects right now for GNOME Outreach Project for Women to apply to: https://wiki.mozilla.org/GNOME_Outreach_Summer2013 thanks to Liz Henry and Selena Deckelmann

If anyone else at Mozilla has a project that can be done in 3 months time (or at least give the contributor a sense of accomplishment and get them very engaged as a Mozilla contributor) feel free to add a project (and a mentor) to the wiki. Applications are being accepted via GNOME until May 1st.

One of my favourite things about this program is that it allows someone to ‘intern’ with Mozilla without the requirement of being a student. If you can help tweet/share the project, that would be much appreciated too. This project has been growing exponentially every session and is making a significant impact to FOSS community and culture.

https://live.gnome.org/OutreachProgramForWomen

Why isn’t Autoland working?

This question comes up enough that I figured a quick blog post/status update would be helpful.

What does Autoland do?

Poll individual Bugzilla bugs for an autoland token (currently using whiteboard tags, future Autoland has an extension & webservice that makes polling the entirety of bugzilla no longer needed). When an autoland request is found, the serviced does an automated landing to try for you of all non-obsolete patches attached to the bug if they can be landed cleanly on tip of mozilla-central and either the patch author or a feedback provider have appropriate hg permissions, otherwise it reports back to the bug what the issues were. Upon completion of the try run, a comment is left in the bug stating the results and if a final repo destination (or destinations) was specified (the hg permissions must match up between requester/reviewer and the destination repo(s)) the service can continue on to autolanding the patch(es) to the destination repo.  A comment would be left on the bug when the push to final destination(s) is done.  There would be no reporting back of final build results, that would be handed back over to human eyes on TBPL.

What is Autoland’s status now?

In April of 2012, right before Marc’s second internship ended, we launched a very experimental public-facing version of Autoland and announced it a bit so we could get more people testing it.  This had varying degrees of success.  We got more bugs ironed out but also discovered that Autoland’s daemons for hgpushing and bugzilla polling tend to fall over a bit too often.  When we moved Autoland off it’s staging VM to a more permanent home we lost the status page that would tell us (and developers) what the modules were doing and that really made the workings of Autoland quite opaque.  With Marc leaving at the end of April and my switch over to help with Release Management in Feb 2012  I had kept meeting regularly with Marc and driving the project to completion as much as possible but hadn’t been able to pull my weight on coding for the last 3 months of our time together. This left us with an Autoland that stopped working and no one available to continue to massage it into being the robust system we needed it to be.  I took mention of Autoland out of our trychooser page, try server docs, and have generally tried to downplay it’s existence while still keeping a plan on the back burner for how we will resurrect it as soon as there is some time.

What does Autoland need to be publicly usable again?

  • A status page that can show what modules are running or down, display what’s in the queue, and give a quick visual to users if Autoland is up or down as a result.
  • Nagios alerts on the Autoland modules that let me (and other people interested in helping to maintain Autoland) know when things fall over.
  • At least one person, if not several, who can access the Autoland master VM and ‘kick’ it as needed

This is what’s needed for a short term solution. I know that we have some bugs with our hg pusher module as well as some trickiness in our message queue that, once fixed, would make the overall system more robust.  We need people using the system to be able to catch more of those bugs though, so in the meantime having as close to on-click restoring of the system would be a huge win here.

What does Autoland need to be truly ‘production’ ready?

  • Security review on the code and the BMO extension so that we can move away from whiteboard tags and let people use the BMO extension instead — this gives much cleaner input to Autoland of what is being requested.
  • More VMs to run hgpusher modules on so that Autoland can handle a larger load. Each VM can run 2 hgpushers max so we’d want to be able to grow our pushing farm as the usage of the system increases.
  • Being able to push to repos other than Try.

There is no clear plan to be able to get the system beyond Try landings, but I see automated try landings as still being a huge help so I’d be super happy just to see that part get back to a working state.  This project is no longer a RelEng priority now that I’ve permanently moved to Release Management and Marc has gone on to other internships and more schooling. I can’t promise anything time-wise, but I wanted to provide some clarity into what is needed and put out the “patches welcome” call.  I see Autoland as being a great option for a community-managed project and I want to keep working on it when time permits. If you are looking to become a Mozilla contributor and are interested in automation and web APIs – this might be a good starter project for you. Please get in touch.

 

 

PyCon 2012 and a second wind for PyStar

Pystar flaming 160 150px

Yesterday when PyCon concluded (and I sadly did not win a NAO robot), I drove home with a sense of renewed energy for continuing to work on building the python community I want to be a part of.  I had a tremendously good time at this year’s PyCon. It continues to become a more diverse space and a place where I feel connected with people who inspire and motivate me.

I was happy to (finally) meet Dana face to face, and thrilled to see several women who had attended PyStar events also now attending PyCon. It’s one of the reasons we left last year’s PyCon with the dream  of PyStar in our hearts.  After the talk about the Boston Python Workshop (which was wonderful and thanks to Asheesh for the shout-out) I was thinking about what makes PyStar unique and whether there is a need for PyStar now that many other alternatives exist.  Hard to believe that only a year ago it felt like there was nothing for women in Python and now there’s shirts stating “Python is for Girls” for sale at the expo hall.

So, with all these groups springing up (and the BPW continuing to grow) do we need PyStar? My gut says immediately “yes” because the more groups focusing on bringing women into geek/programming space and having it be safer and comfortable the better.  There’s more to it than that though.  The groups are all doing great with their various organizers and events.  PyLadies, Ladies Learning Code, and Women Who Code are all holding sold-out events, getting lots of attention, and we’re all working hard to get more women connected to a community of programmers where they can learn and develop skills in a ‘safer’ space than historically has been available to women. The Boston Python Workshop is doing a great job of promoting Boston (as well as Python and Workshops) but I realized that for me, the reason I got excited (and am excited again) about PyStar was exactly because it was non-geographically named and because the name itself is for “all”.  I’m very happy to be in the mix with all those groups and yet I recognize that I still want to try to nurture and shape PyStar into its own thing.

I am interested in continuing to explore how to work on this project with a distributed team and to have PyStar events spring up in various communities and be customized to specific needs. Just because SF is heavy into startups and web apps doesn’t mean that San Antonio, Texas will be – maybe they’ll be more into big data and hardware hacking.  I like the idea of PyStar developing and hosting a wide variety of curriculum for python-driven projects in a central repo that can be cherry-picked as needed by anyone in any city who wants to lead a workshop day/weekend/afternoon. I especially want to figure out how to repeat what I did in Paris last summer, where I managed to organize a PyStar for when I was going to be there visiting. That certainly required some existing connection to the town (Mozilla/WoMoz) but the idea of traveling and setting up shop anywhere a hacker group/women’s community/library can host – that’s exciting to me and carries forward the DIY/punkrock way I’ve always known how to get things done.

In the talk at PyCon, one of the BPW’s stated goals is to try to build up within existing user groups. I see their logic, and it’s sound, but I was not a member of the BayPiggies (the Bay Area PUG) when I first was inspired to start running PyStar events in the Bay Area and I still don’t see the need to be. There are several places where I can announce upcoming workshops, Baypiggies have a mailing list I’m on, and I can promote PyStar events and make sure other groups are in the loop about what we’re doing.  I think this more than satisfies being eligible to be part of the larger Python community, and yet there’s room for more than one Python-loving group in any community. I’m not always looking to insert myself into an existing group – there is something to be said for creating new things and building them with a certain tone/mission in place at inception. That’s what I get out of PyStar, it doesn’t have a legacy or a way things have always been done – the spirit of PyStar is one of distributed organization, shared responsibility, and communal education.

Here are my specific goals for this upcoming year of PyStar:

1. More curriculum on the PyStar site – workshop material that is discoverable by level (beginner, intermediate, pro) and by time commitment (half day workshop? full day? multi-week?). A new person  interested in organizing a PyStar event should be able to see an easy-to-follow list of what to do to set up their own event based on time and level. This can be accomplished through more research on finding existing curriculum and adapting it, more events where we can test and fine tune those curriculum, and also having curriculum hack nights with PyStar organizers and volunteers (multi-city) where we focus on developing material to fill gaps in our topics

2. Have PyStar SingPath tournaments both locally and with other PyStar outposts. While the one I did at PyCon 2012 was a nerve-wracking experience, it was ultimately a confidence-boosting event for me. I encouraged a few women to come try it and it seems to be a pretty fun way to maintain the energy as well as test your new skills between workshops. We can tailor the tournament to be _very_ friendly (prize/badge for all, just for participating). I read/heard something recently about how leaderboard style of competition is not that motivating for women and that beating your own previous results is much more fulfilling.  We can definitely work that into our tournament styles by awarding prizes for most improved and other metrics that a person can get by just doing better than they did in previous tournaments.

3. Incorporate Open Badges into the PyStar curriculum so there is measurable outcome for completing projects and implementing the handing out of badges through the PyStar site. Gregg and I are already talking with Mozilla about their Open Badges project and will continue to keep an ear to the ground on how to implement this into the PyStar site. It would be nice to have a meeting with all interested PyStar organizers to brainstorm on what our badges could be.

4. Find non-profits who need small projects (simple website, automation) done and have no budget – match them with PyStars who would like to learn. Possibly have a connection section on the PyStar site?  Have PyStar leaders be ‘project managers’ and bring a project to fruition through regular PyStar meetups? This is a longer term goal, but one I like to keep floating out there and gauging people’s reactions to. Usually the reaction is “great idea! lots of work!” :(  My vision here is something along the lines of a a template for ‘how to build a (info, fundraising, blogging) site for a small non-profit with a newbie webdev team’ curriculum.

5. A stronger focus on intermediate level programmers. Not to the exclusion of beginners, but to be sure there is room to grow within PyStar This comes up a lot in SF/Bay Area and I know it’s different in each city.  In SF/BayArea it seems really important because there needs to be something to hook in the women who have programmed in other languages or who are CS majors who seem to lack the confidence in themselves now that they are out in the workforce – with many of these participants, it doesn’t take much to remind them how far they are from a newbie – I would like to focus on them a bit more because a) no one else seems to do so b) it provides more volunteer potential and alum/badges c) mentoring opportunities for newbies and job networking for the intermediate level programmers among each other

6. Continue to develop strong connections with PSF, BPW, PyLadies, and __insert_group_here__ organizers. – I should have proposed a BOF at PyCon for organizers to get together and share plans — I would really like to work alongside these other groups in a sustainable way, we all have admirable goals and could share some resources and people-power.

7. PyStar gear & promo materials, fundraising. Set up a cafepress store to sell some PyStar goods and also try to get a few donations to set up an account for PyStar that would allow us to a) pay for the domain name I just renewed b) potentially buy other domain names for side projects we come up with when we work with non-profits  c) cover the costs for creation of handouts, cards, other promo materials to give out at events promoting PyStar

Get involved!  The project currently lives in github and organizers/contributors can reach each other through our mailing list.  If you want to host an event, help with curriculum, or otherwise work on making safer spaces for learning Python happen in your own community, get in touch.

Autolanding your patch(es) to Try via Bugzilla

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

There is a threshold on how many bugs the autoland system will push and track at a given time.  We are curious to learn about usage and load on this system so please give it a try and inform us of any issues in IRC: #build or #developers channels are the best places to find myself (lsblakk) or Marc (mjessome) and chat us up about this initiative.