Mchua

My name is Mel Chua, and this page describes the Sugar-related projects I'm working on. Feel free to contact me with any comments, questions, or ideas you might have, or check and see if I'll be traveling near you sometime soon.

English is my native language. I have a basic understanding of ASL. 这个用户是能够有助于满足于基本 水平的 中国人。 この利用者は少しだけ日本語を話すことができます。 Estoy aprendiendo español. Sto imparando l’italiano. Ako ay pag-aaral ng Tagalog.

Quick reference

You might be looking for...

• My talk page - for leaving me a message.
• My Planet Sugar Labs blogposts.
• /proposals - Thoughts in progress that are not yet fully formed or ready to go to main wiki. Probably inaccurate, half-baked, or some combination of the two. You have been warned.
• /Firefox shortcuts that may be useful for wiki users.

SLOBs position statement

I don't particularly have a position statement, but here are some materials you may find helpful in figuring out what I'm likely to bring to the table. The shorter summary version that recaps most of the rest of this page can be found on my blog.

Goal

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. In order to do that, Sugar Labs has to be at a point where more new volunteers can come in and get up to speed - right now it's a struggle for even experienced contributors to simultaneously keep up with what's going on, contribute in the way they want to help, and have a life outside of Sugar Labs (it was barely manageable when I was volunteering more-than-full-time at the start of 2009).

Ultimately, I want to run merrily through the jungle with troops of new recruits, showing them trees and vines and berries, introducing them to people who can teach them about birds and fish and hut-building. But the paths aren't clear for running yet; someone's got to take a machete and get the underbrush out of the way. I'm willing to serve a year or two in the SLOBs Machete-Wielding Corps, hacking slowly through thorns, aching to run all the while, because I know it's what will eventually give me and many others clear routes to sprint full-tilt-ahead at where we want to go.

Deciding to run

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 was previously in "mehhh, I'll put my name here as a placeholder and decide later" mode, but now I'm just going to go for it full-tilt.)

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.

Someone's got to do the non-shiny gruntwork, and the project management and capacity-building-fu I've been learning in Fedora for the past few months seem like skills SL could use at this stage in its growth.

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

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.

So I think SL could use more "fire drill" procedures, since... at some point, we may need to make a decision that we can't wait for a 5-week, 300-email thread consensus on. I think such decisions will be exceedingly rare. I'd like to have insurance that we know what we will do with them. I'd like to guide SL through the process of thinking some of these scenarios through ahead of time so that if they ever happen, we'll already have frontloaded the community consensus process, and can just proceed.

Interests

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:

1. What do you want to do?
2. Why aren't you doing it (or what stops you from doing it better)?
3. Why don't you and others know (or know more) about the exact impact that you're having on how children learn?

My background is in engineering, so I'll often tackle things through technical tools and the people who want to work on them, and use software-based analogies and processes to get things done. I'm a student of education (and learning) as well as business operations - I'm by no means fluent in those two domains yet, but I'm trying hard to become equally comfortable working within and with them. Help and feedback is always incredibly appreciated.

Projects

I tend to set my goals in 6-month cycles mirroring the Sugar release schedule. This list is super-flexible; stuff changes all the time, random cool ideas come up, and so this has deliberately been planned with lots of wiggle room. As things change, I (usually remember to) edit this page to reflect that.

I was sidelined with RSI for much of the previous release cycle (and am still recovering), so priorities have been adjusted accordingly. For this release cycle, I've put all my projects aside under the "future" category until after the SLOBs election when I'll know how much time I have to work on them (or if I get elected to SLOBs, how I can work on them as part of that role).

Please feel free to steal a project if you like it, and let me know how I can help - I don't care who does this stuff so long as it gets done.

Future goals and projects

Feel free to pick up on these or let me know if you would like to help!

Entry points for all SL teams

Goal: There should be at least one mapped-out-and-tested new contributor experience for every SL team - something that takes people from "I want to get involved with Sugar by working on this team" to independently contributing and able to mentor newcomers to that team themselves. This should be done by contributors who want to personally experience, improve, and document them, and encourage others to go through them and give feedback. (All these things would be done in partnership with and with the approval of Team leaders.)

Here are projects for each team that could be picked up. I am willing to help match people with mentors for each task. The point of doing these things is not just "do this for team X," but to explore how welcoming team X is to newcomers who want to contribute, and how this experience could be improved - think of yourself as a mystery shopper, except not-so-mysterious (the fact that you're doing this to test out "newbie routes" is totally transparent).

• Interviewing Sugar Labs contributors for profiles for the Marketing team.
• Maintain the IRC Activity for Activity Team.
• Run at least one BugSquad sprint and mentor someone else in running a BugSquad sprint for BugSquad Team.
• Provide a weekly feedback report to Deployment Team for the Sugar deployments I'm involved with.
• Produce the next draft of a Sugar Deployment Guide with Deployment and Documentation teams, possibly at another FLOSSmanuals sprint.
• Work with Documentation Team to make guides for how to get started in each community team.
• Work with Design Team to design and execute an appropriate small project for this cycle (perhaps a "get swag!" listing page).
• Have at least 4 accepted patches to sugar-core or SoaS for this release cycle for Development Team.
• Run an Activity Team/Development Sprint with a strong focus on educator feedback for the Education Team.
• Define and offer hosting service packages for Local Labs and Deployments with Infrastructure Team.
• Write a monthly group profile for Marketing Team.
• Make (or improve) a redirect bot for Wiki Team.
• Doing QA for the Addons Portal project. The first step is to find out (or write down) testing and feedback cycles for its development.

Well-defined open tasks

SL's trac should include a component for each team's tasks (not just code bugs!) and also a keyword for newbies to search for, so we can tag getting-started tasks. Each of these getting-started tasks should have a mentor associated with it and information that would enable each newbie to find that mentor to shepherd and sponsor them through the beginning-contributor process. Finally, the task log should be kept populated with useful things to do and monitored through at least the first dozen newbies to see how they experience it, then passed on to one of those newcomers to maintain. I would be willing to mentor this task.

One could imagine a similar (maintained) list of open projects (concrete accomplishments larger than a single task). This may actually be a better place to start. The first task would be writing up a short guide as to what constitutes a good project proposal and submitting the draft to iaep for feedback. I would be willing to mentor this task.

Local Labs formation and communication should be easy

There should be a guide and case studies for formation of Local Labs. The interface for participating this way should be clear - what is a Local Lab? Why would you start one? What are the requirements to do so? And so forth. This is probably best done in conjunction with groups who are in the process of starting Local Labs right now. I would be willing to help find someone to mentor this task (I imagine there are better mentors for this than me).

History

I left this section blank for the longest time - and 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. But here are a few points to ask about, and folks who you could ask, to get you started.

• The June 2007 Game Jam, when we went (in two days!) from no community Activity maintainers, or even co-maintaners, to 10 entirely community-created-and-maintained Activities, with 3-4 maintainers for each Activity; Brian Jordan and Wade Brainerd joined us here.
• The community QA team, which I ran as part of my role as an engineer at OLPC, and how this helped us by getting testing done, but also by figuring out upstream-downstream relationships between OLPC and the newly-born Sugar Labs, and by giving new volunteers an on-ramp to get involved with development. Tabitha Roder and the Welly testers were heavily involved with this.
• My presence during the first 2 Sugar Camp gatherings in Boston during fall and winter 2008, particularly the talk that Greg DeKoenigsberg and I did on community (during which I didn't actually talk - find the videos to see what happened when I used my talk time to introduce and hand the podium to new volunteers instead) and the ending cool-down discussion that most of the current SLOBs were present for.
• My brief tenure as ad-hoc Marketing team lead, in the gap between when Greg DeKoenigsberg stepped down and Sean Daly came in.