Since RSI took me out of the loop for a few months this summer, I thought it might be good for me to introduce myself to new folks and explain why I'm running in the current SLOBs election. I've never run for any position in the open source world before; for the past 3 years, I've found myself able to contribute to my fullest without the need for any title or access beyond that which any other contributor would get. I'm running now because I think that's changed.
I don't particularly have a position statement, nor do I have campaign promises. The way I see the state of the community is less important than the way we as a myriad of individuals see the state of the community, and things are changing so rapidly at Sugar Labs (as they ought to be!) that the only promise I feel comfortable making is to be present and react to changing situations as best I can. I think it's more important to know who people are than what they promise to do at a specific frozen point in time. And I can't tell you who I am - but I can try to show you.
With that in mind, here are some materials you may find helpful in figuring out what I'm likely to bring to the table. These are the summary versions; the longer ones are on my user page. Don't read them as platforms or as promises; read them as a glimpse of how I think and how I operate. Ultimately, we're not electing platforms or promises; we are electing people. This is me.
My goal in running for SLOBs (longer version)
I want to be on SLOBs so that I'll never have to be on SLOBs again. The work I really want to do its capacity building within the Sugar Labs community, bringing new volunteers in and up to speed. I can't do that right now; there's too much underbrush in the way. I'm asking for the SLOBS machete for a bit so I can help hack Sugar Labs into the kind of community I would like to contribute to - and the kind of community I'd be able to contribute to - so that I can, as quickly as humanly possible, go back to being Just A Contributor.
Notes from when I first decided to run (longer version)
After a lot of internal debate, a few long conversations, and a hard look at the calendar/project-list clearing I'd have to do, I've decided to run for SLOBs, because I think that's where my limited time for SL (and it is limited) can best be spent...
I'll have to give up my dream of dabbling in various bits of Sugar code for fun (it's slowly becoming apparent to me that I may
never be primarily a coder again), and I'll have to apply a serious amount of discipline towards staying in the loop consistently, which has been tough as my schedule's fluctuated and I've started to travel for work (YAY!). But I think that's a fair tradeoff if it makes me more able to blast blockers out of the way of other people - including my future self, who'll be a lot more effective at SL recruiting once a framework to capacity-build atop has been put more solidly in place...
Challenges I can foresee:
- consistently clearing the time to make SL stuff happen. I know that if it isn't on my schedule, I will probably not do it, so I'll
need to schedule SL in and stick to it. - having the discipline to make sure the SLOBs todo list stays up to date and on track, if needed... ;)
- bias - my history with OLPC and current ties with Fedora mean that I will have to be very conscious of the ways this might affect my positions on some topics, and excuse myself when needed.
- restraining my tendency to want to make everything transparent Right Away, without squelching or diminishing that tendency - defaulting to open is a great setting to have, but "default" does not mean "the only option," and I still struggle to balance this desire with prudence and practicality.
- not getting distracted by shiny stuff. I'm pretty sure SLOBs will take up most of my "SL time," so making sure SLOBs stuff gets done first will take more of that "discipline" stuff I've been practicing...
On consensus (longer version)
From explaining to a friend why I was asking lots of what-if? scenario questions during our conversation.
No matter what happens, we'll be able to improvise and get through it okay; SL people are good people and smart people and stuff is going to work eventually. The question is, what values of $work and $eventually are we willing to accept?
It's like having a fire drill in school. It's not that everyone wouldn't be able to get out on their own, given sufficient time. I mean, everyone is generally pretty smart, and tries to get away from fire. But because in a fire, time is precious, and people get panicked, and you can't just "get out eventually," you need to get out NOW, you have a fire drill, so everyone goes "okay, this is how it would work," and it turns into more of a known factor; you know how all the pieces would coordinate ahead of time... if they ever appen, we'll already have frontloaded the community consensus process, and can just proceed.
Interests (longer version)
I'm a community engineer. That means I'm something of a jack-of-all-trades - my primary interest is in making it easier for
contributors (or potential contributors) to Sugar Labs to do what they want to do, and to keep radical transparency going throughout the project so that the efforts of individual volunteers are all aimed towards furthering the mission and vision of Sugar Labs as a whole as well. Basically, I try to nurture leaders into and within the community, get them to work interdependently with each other, and sledgehammer junk out of their way so they can do Real Work. Or in other words, I ask these questions all the time:
- What do you want to do?
- Why aren't you doing it (or what stops you from doing it better)?
- Why don't you and others know (or know more) about the exact impact that you're having on how children learn?
History (longer version)
I left this section blank for the longest time... the best way to find out my history is still to pop on the #sugar IRC channel and ask around about who mchua is and what I'm like and what I do.
Thanks for reading - and thanks for everyone who's supported and encouraged me through going through my first election. Whee!