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.