User: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.

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.

Current goals and projects

I tend to set my goals in 6-month cycles mirroring the Sugar release schedule, so these are my goals for the the 0.86 release cycle (March 1, 2009 - September 1, 2009). 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 this release cycle, so priorities have been adjusted accordingly. For

• Google Summer of Code 2009 co-coordination with Jameson Quinn, focused on linking each student project with a Sugar deployment for testing and feedback (including starting a SoaS pilot near them, if needed - this is how I'd prefer to do it).

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 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 do stuff. This page needs a facelift.