Posts that are sugar-ish

Curious artifacts: a POSSCON talk


Welcome, remedy POSSCON attendees! This blog post is the virtual home of the talk Sebastian Dziallas and I (Mel Chua) did on Thursday afternoon, medicine titled Curious Artifacts: Making FOSS Materials Make Sense To Learners. Our talk materials were, condom in large part, created with the audience.

The goal of the talk was to get audience members to actually look at live open source projects and start analyzing how those projects might fit into a high school or college classroom. When you look at a project, what cool things grab you, and what sort of little annoyances irk you? How can we turn them into the sorts of mini-project-opportunities students can tackle, and how do we build materials and scaffolding around those tasks that can be used as scaffolding – worksheets, reading, discussion prompts, homework assignments, grading rubrics?

This is a big job – so the trick was that our POSSCON talk started on Thursday… and was the kickoff to a conversation we continued online. Our intrepid audience volunteer Kevin came up and modeled the beginning of a first-contribution conversation using the original bounty Sebastian posted on Tuesday night, then the crowd split into teams and attacked printouts of FOSS artifacts with red and blue pens and highlighters. And smiley face stickers. Always gotta have the smiley face stickers. The audience critiques are available here (pdf).

Here’s the flyer that was handed out during the talk in lieu of slides (available in pdf and odt format for remixing) to guide participants through some of the tools, terminology, and cultural quirks they’d be encountering as they looked through the material to critique.

One big analogy used throughout the talk was open source as a cultural immersion experience similar to study abroad. This theme was used for the beginning and end. Some key points made:

  • Study abroad is not just about taking the same math class in Paris that you could take back in Wisconsin. It’s about the experience of being in Paris – language, culture, transit system, food – math class is almost incidental. It’s the same way for open source. Students need to watch, appreciate, be prepared for, and make time for things outside their course material in order to really benefit from the experience.
  • You’ll be in an unfamiliar environment. Simple things will be awkward at first – ordering a glass of water, fixing a simple bug. Keep going – yes, you could order water in English, but you’re in China so you can learn how to do it in Mandarin! It does get much, much easier after the first time or two.
  • The point is to get out and experience the culture. Immerse yourself. Don’t just hang out with other expats or foreign students. Whenever possible, bring your students into the real world, real conversations, real materials… the point isn’t memorizing all the Italian verb conjugations perfectly, but to communicate with someone in Italian, no matter how broken. You’ll learn through conversation, so get out there and talk!

If you were at our POSSCON talk and want to add materials – comments, pictures, thoughts, anything – to this post, leave a comment.

Thanks for listening!

–Mel and Sebastian

Some pictures from the talk courtesy of Zenith Chua (thanks, Mom!)

Our brave audience volunteer Kevin explains his critique of Bug #180 in the Fedora QA trac.

Audience members critiquing FOSS artifacts at POSSCON 2011; the image shows several people at the front of a room, with one man holding up a sheet of paper he is talking about into a microphone.

An audience review of the Fedora Design team's meeting logs and bounties. I believe smiley face stickers were involved.

Audience members critiquing FOSS artifacts at POSSCON 2011; the image shows several people listening to a student in a black shirt explaining the webpage his group reviewed.

Verdict: Sugar on a Stick's websites contain way too many unexplained acronyms. We should do something about that.


Please take the Ada Initiative’s 5-minute census


With a week to go before SIGCSE – the largest CS education conference in the world – begins, healthful my inbox is starting to fill with emails about corporate sessions, help enter-this-survey-to-win-this-fabulous-prize teasers, medications and other “industry attempts to talk with academics, insert shiny stuff here” messages. Is this… normal? Is this how companies and professors usually engage with each other? Good lord, how do people have conversations in all that noise? One of my biggest worries about the conference for myself is that I’ll be so overwhelmed by the bigness of it all that I won’t be able to step back and take time for the meaningful connections that I want to have. I’d rather have 5 excellent conversations than 500 spamlike rocket pitches, but I know that’s my own (somewhat introverted) preference; I’ve always been on the shy side and not really one for crowds.

I’ve found writing to be a good way to let me get those deep experiences while also sharing them with a much wider audience – and so today we kicked off a planning discussion on opensource.com/education and TOS tag-teaming to cover SIGCSE.

I’d like to get a flood – nay, a tsunami, a malestroom – of content coming out of [SIGCSE] – stories that tell people who we are, what we do, and why we care so much about it.

We could use help with the following articles – anything from authors to take ‘em (we’ve got editors and artists and whatnot to help) to feedback and suggestions on what to cover. So for anyone who’s ever wondered what happens when over a thousand CS professors get together, we’d love some thoughts on:

  • Lay-of-the-land before the conference: What is SIGCSE like? I’d love to have someone who’s been to SIGCSE before write this; holler if you’re interested.
  • Which sessions should we cover? The schedule is huge – we obviously can’t cover everything, so we’re going to have to take requests. If you’d like a session covered for any reason (one you can’t make but would like to find out about, one you’re presenting and would love an article on), please holler – with the caveat that it’s going to have to become an opensource.com article somehow, so we might have a tough time covering a panel on the benefits of NDAs, sorry. Also consider the HFOSS symposium while making these suggestions.
  • Who should we interview? I have a video camera and a sound recorder. Matt Jadud has a video camera and a sweet, sweet SLR. There’s a giant list of presenters, and even more attendees. Who do you know at SIGCSE with a great open source story we should tell? How can we find them?
  • Post-conference roundup: This is an easy one for a remotee – if you wished you were coming
    to SIGCSE but can’t make it this year, this would be a way to integrate
    yourself into the conference happenings from afar by synthesizing and summarizing everything that goes out during the conference, and poking authors there-in-person to go find out things for you.
  • Any other ideas?

Also of note: SIGCSE takes place in Raleigh next year, which is the location of Red Hat’s headquarters. I’d love to see the Teaching Open Source, Fedora, and Red Hat crowd collectively mastermind something really bloody spectacular for this. Open the floodgates for ideas – what should we do? Custom Fedora SIGCSE remixes, a FAD happening in parallel, a big “I wish students would help my open source project!” contact list, a gallery of FOSS student work, dancing pandas?
Passing on a message from the Ada Initiative, what is ed
a group doing what I personally believe to be incredibly important work on gender representation in free and open source software, sovaldi sale content, and culture – precisely the things the Fedora Project is working towards the rapid advancement of. The survey really does take less than 5 minutes; regardless of your gender, please give it a shot!

Take the Ada Initiative Census

The Ada Initiative is a newly-formed organisation which aims to support and promote women in open technology and culture. We’ve just launched our first annual census — a broad survey of open technology and culture participants — to find out more about what projects and communities people are involved in, and how they feel about women’s inclusion and representation in the field.

We use the term “open technology and culture” to refer to a wide range of activities and communities based around free/open licenses, and other forms of open, decentralised, and grassroots participation in technology and related fields. This includes:

Open source/free software
Open source hardware
Open geodata and maps
Open government
Open data
Open standards and formats
Open educational initiatives (open access journals, open source curricula, etc)
Open/decentralised social networking (including Diaspora, StatusNet, etc)
Creative Commons and free culture
Wikipedia and other wikis
Open crisis response and humanitarian projects
Barcamps and unconferences
Online/digital activism
Remix/mashup culture
Transformative works fandom, including fan fiction, fan art, and fan vidding
Maker/DIY community
Hacker spaces
Coworking

If you’re involved in any of the above areas, we’d like to get to know who you are, what you’re working on, and your thoughts on how women are doing in your community. We welcome participation by people of any gender, although we are particularly interested in women’s responses.

The survey only takes about five minutes, and can be found at https://www.surveymonkey.com/s/adacensus2011-email.


Join Nicholas: chronicle the start of your own FOSS adventures


Nicholas Whittier’s blog isn’t (yet) on Planet Teaching Open Source, sale so I’m going to cross-post this, overweight because I was excited to read it. His New Year’s Resolution is to start participating in open source projects – namely, Habari and GeoServer – and he’s going to document the process as he goes along.

…I have used and promoted open source software for as long as I have been aware of its existence. I talk the talk, and I have met with success when ‘selling’ open source software solutions to my employers. But I must admit, I have not really been walking the walk… the extent (to date) of my open source ‘walking’ has been logging a few dozen bugs for various projects, a couple of minor documentation updates, and a couple work weeks of forum postings and mailing list responses. Not terrible, but I know I can do better… so, my resolution is to cut down on my internet browsing, and fill it with mailing list/IRC/Forum participation, documentation updates, QA, and coding for a few open source projects that are important to me. I plan to document my experiences with some of these projects, and offer any insight that I can to help others who are interested in getting involved open source. I’m planning to get much more involved in Habari (PHP – powering this blog) and GeoServer (Java – I use GeoServer in my usual geo-spatial stack). Because I have different levels of comfort in these technologies, and because the projects are run very differently, these two projects will offer a great way to look at some of the diversity that is possible in open source participation…

That’s where I am at the end of 2010. I’m taking baby steps here, and aiming to be an active participant in these efforts with submitted code, bugs, and documentation updates during 2011. Future posts on getting started in open source will likely compare my experience of similar activities, and how they proceed in the two distinct projects. I hope this way of dispensing my experiences will offer easy ingestion for users interested in different projects, as well as users with distinct skill sets. Hopefully the variances between the two projects will allow a good deal of data for each step along the way. Stay tuned for a ‘Getting started in open source participation’ article on exactly what I’m doing to get my foot in the door for these projects, and a little bit more about what I’m expecting in this effort.

I’m very much looking forward to reading these posts, and have encouraged Nicholas to tag them so they’ll show up on Planet TOS – he’s a keen writer with the ability to reflect on his mental processes while learning something as a novice, which is something that will be incredibly valuable for any open source project trying to get insights into how the participation process looks like from the newbie side, and also to newcomers looking to read about the thoughts of someone going through the process they’re about to launch into.

I hope that more newcomers join Nicholas in writing down their thoughts as they begin their own FOSS journeys. It’s actually the sort of thinking and contribution that we typically lack the most – and something that experienced contributors cannot do. I have some of my own thoughts in this blog from several years ago when I began actively contributing to open source, but they’re faded and fuzzy and I
wish I’d done more (I was confident that nobody would care, but as it turns out, I wish I had written more down).

Too often we’re only publicly reflective only when we’re confident and experienced with something – so I applaud (and admire!) the courage being demonstrated here. Good luck, Nicholas – please keep writing, and let us know if we can help you with your adventures in any way.


Get-sugar instructions – newcomers needed for usability testing


Sugar is too hard to download and install. Walter was recently surprised to hear (during an interview) that even “advanced users” (I’m assuming he meant the computer-savvy who were new to Sugar in particular) had difficulty with our installation instructions, buy so he went and did something about it.

Walter’s new revision draft is meant to be an improvement over the current Downloads page (last edited August 21, try 2010).

I offered to try and drum up some testing to see if this is actually an improvement, and what remaining rough edges need to be sanded off. The catch is that most of us can’t help with this directly, since we probably already have Sugar running on our machine and are used to getting around the current install instructions to make it work. Therefore! Here’s what you can do to help.

If you’re a Sugar old-timer and can figure out the new install instructions with no trouble:

Congratulations, you’ve learned how to work around our existing documentation! Find yourself some newcomers and sit down with them and work through instructions below in person – remember to send things to the iaep list so we can all learn from it!

And remember, when they’re looking at the page, don’t say anything – don’t take the keyboard from them, don’t do things for them, don’t interrupt them. They’re doing very important work – the work of telling us exactly where the shortcomings in our documentation are. When they point them out, help them by fixing the documentation together and then allowing them to continue proceeding by themselves.

If you’re new to Sugar or think the install instructions are hard to understand:

You are exactly the kind of person whose help we need. See, most of us have been using Sugar so long we’ve forgotten what it’s like to be a new user puzzled by install instructions – we’ve lost the ability to improve them because we’ve gotten too used to how difficult they are to understand. Here’s what we’d love help with.

  1. Check out the proposed redesign for the download/install page.
  2. Try to get Sugar running – whatever platform you have, whatever means you’d like to use. Do not ask for help yet, even if you’re getting stuck. We’re trying to find out whether the instructions on that page – and linked from that page – are sufficient to enable folks to get through the installation on their own.
  3. If you do get stuck, write down (or take a screenshot and circle) everything you can think of about what’s confusing about the page, what you had to take a guess at, and as much as you can describe about where and why you’re stuck. This is incredibly valuable feedback that only you can give – you’re showing us how our documentation can be improved, pointing out things we don’t realize we ought to fix – until you come along and tell us. (If you manage to make it through to the end, this sort of feedback on how it could have been better is valuable anyway – but you can also skip to step 5).
  4. Now that you have these notes written up, take them and send them in an email to the it’s an education project mailing list (iaep at lists dot sugarlabs dot org). If you cc me (mel at sugarlabs dot org) on the email, I’ll make sure your feedback gets looked at and brought to the right people.
  5. After you send that email, someone should come along and help you finish the installation. When you have Sugar working on your machine, if you can drop us a line again (on the iaep mailing list, and cc me) so we know you were taken care of and that things are working for you now, we’d very much appreciate knowing that you’re all set.

Thank you!


Teaching Open Source: a mental model of the TOS community


I sat down for a while yesterday (okay, dermatologist stood up while scribbling on a whiteboard) trying to get down my current understanding of the TOS community and what it is and where it could go. Looking for feedback, psychiatrist especially from folks who disagree – this is a braindump meant to spark conversation, coming from an individual in the community trying to express her own mental context of it.

This video is licensed CC-BY.

High-level summary:

TOS is a community of practice of people who teach open source community participation in an academic context. It’s not a teaching or research institution, a company or nonprofit, a software project, or a professional society, though many of its members belong to one or more of these, and we make use of their structures in order to accomplish our goals.

Our primary deliverable as a community is academic source (this term feels a bit awkward to me – perhaps there’s a better existing one from the teaching world?) – artifacts that assist the transfer of the ability to teach open source community participation in an academic context. Things like workshops, syllabi, curricular materials, handouts, etc. are tools to accomplish our goal, which is a human-to-human transmission of teaching, rather than the end-all-be-all themselves.

Several parts fit into this:

  • Conferences and events in both the FOSS and academic worlds as public spaces, gatherings where we can swap this knowledge. Individual institutions, to some extent, will always be black-boxes and more private spaces; that’s okay.
  • POSSE as an on-ramp into the community; you don’t have to attend POSSE to join the TOS community by any means, but if you’re interested yet don’t know how to start, it’s a good way to get up to speed.
  • Infrastructure to support digital communication within and between institutions, both hosting and maintaining it within the institution-neutral space of TOS, and helping those who want to set it up within their own institutions.
  • Grants to assist with all three of the above.

Open question: what value does the TOS community create for each of its participants? (In other words, why are you here, and what does your school/company/project gain from your participation?)

That’s it – I’d love feedback and thoughts on this.


Heads-up: call for Sugar 0.90 testers will be coming soon


From the latest Sugar on a Stick (SoaS) meeting minutes:

We spent most of our time on the next big urgent milestone: getting testable Sugar 0.90 images out the door for upstream Sugar QA. This isn’t an official SoaS release, find but since SoaS is an easy way to get an instance of Sugar up and running, it’s great for testing, and since we’re going to include the 0.90 release of Sugar anyway, Simon has asked us to include it in our test builds by a certain date so it can be used to test the Sugar environment itself. By “certain date,” I mean that the 0.90 Beta release is this Wednesday; here’s what has to happen preferably before then. (For the Fedora folks in the audience, SoaS is a Fedora Spin.)

  1. Simon updates the sugar, sugar-toolkit, sugar-datastore, sugar-presence-service, sugar-artwork, telepathy-gabble and telepathy-salut packages in Fedora to the correct code versions.
  2. Mel gets 3 people to test these packages and give them karma in Fedora’s system, which will put them in the stable repositories. I’ll be writing instructions on how to do this shortly.
  3. Simon or Peter or someone takes the next daily build and makes sure it boots, then announces the test image.

What this means for you, o reader: if you run Fedora (or can run Fedora in a VM, or can follow written instructions on how to do exactly this), you (yes, you!) can help us with 0.90 testing this week. We’re going to have instructions for this coming out once the code is ready to be tested; it should take less than 2 hours (hopefully less than 1) to do your setup and testing from start to finish, and you won’t need any prior experience. We’ll be using the same test setup for Sugar in the future, too.

The catch is that because we’re under intense time pressure to meet release deadlines, the time between when we can say “we’re ready! We need help!” and when we need the testing finished by is going to be VERY short. So this is a heads-up letting folks know this call is going to be coming.

Stay tuned for more QA news in Sugar land! (dun dun DUNN!)

This blog post written under more sleep deprivation than is probably good for me. I’m going to go to bed now so I’ll be more useful in the morning.


What FOSS communities can look like from the outside


I found this mailing list conversation snippet to be very insightful, pharmacist and wanted to share it.

Scott: “Open to critique” isn’t quite the same as “responsive to critique”. From an outside perspective, visit it seems that frequently SugarLabs is just not listening to people who offer contrary opinions.  This is better than flaming them, information pills but maybe not as good as it could be. For an end-of-year report, I’d like to see instances enumerated where SugarLabs actually internalized some outside critique and responded in a positive way — some concrete change made to the UI, or Sugar, or to process.  That would be more convincing that simply stating, “we are now open to critique”.
 
Bernie: We’re definitely intimidating to non-technical people. At least, this is what I sensed at the Realness Summit. OLE also seems to be doing a better job at connecting with educators. I’m not completely sure what corrective actions should be. We might need to do some work on the  wiki, maybe add web forums, which non-geeks tend to prefer…

Scott: I suspect that the answer to this problem does not involve installing additional software.

Later in the day, Jeff and I were having this conversation on #teachingopensource.

Jeff: Is IRC really a barrier to entry?  maybe I have simply been using it too long, but it seems immediately recognizable to me. I think one barrier might be the attitudes that crop up.  Even with emoticons, sometimes it’s hard to discern intent.  Hard enough in email, but sometimes devastating in real time.

Mel: Actually, yes. I had a really, really hard time figuring out IRC. First, figuring out that it existed and I had to use it. Then how to get it, how to set the software up. Then what the heck networks and channels and whatnot were – and why channels? my IM paradigm was “you have a buddy list and you ping people individually.” So “chatrooms are the default!” wasn’t hard to understand once I realized it, but it took a while to realize because I wasn’t looking for it.

And then “oh man, who are all these people? I am nervous about pinging them, will they yell at me?” And then all the /commands I had to remember. It was so bewildering and terrifying and new and it was being used as a way to present new information to me at the same time, sort of like… taking your first calculus class in… Mandarin, if you’ve also just started studying Mandarin as a foreign language. You can’t concentrate much on the calculus because you’re going “zomg it’s in CHINESE.”

It’s hard to remember how hard things can be, especially when you’re surrounded by a community of people who are the ones who self-selected and made it past that hardness. By definition, if you’ve gotten into FOSS, the current participation mechanisms worked for you… so why fix them?

Because we want others to join us.


irssi + screen quickstart


Notes I wrote up months ago that have since been found by others to be useful. Posting for posterity. Basically, try these instructions are for how to set up an always-on logger for IRC (chat) – helpful for being able to hear the conversations others are having about the project you’re working on while you’re away. I am assuming a fair amount of background knowledge here, but the content is remixable, so feel free to yoink/improve/etc.

1. ssh into the box you have an account on – for instance, Sugar Labs folks can use sunjammer (aka people.sugarlabs.org) by requesting an account at http://wiki.sugarlabs.org/go/Sysadmin/Shell_account_request
.

2. Run these commands (comments in parentheses).

screen

(a dialog will pop up, hit return to kill it)

irssi

(you’ll get a mostly blank screen, with a stripe across the bottom with the
time and a number [1] in brackets – that’s the window list – and then a line
below that with [(status)] in it, which is the description of the window that
you’re in, and the place you type the rest of the commands.)

/connect irc.freenode.net

(and then, if you want, /msg nickserv identify <password> to sign in.)

/set autolog on

(it’ll start storing things in ~/irclogs in self-explanatory filenames)

/join #sugar

(and whatever other channels you may want to be in)

(You’ll notice that every channel you join opens up another window – the first
channel will be in window 2, the next in window 3, and so forth. Use ctrl-p
(previous) and ctrl-n (next) to switch between windows, or alt-NUMBER to jump
to the NUMBERth window.)

(You’ll also notice that the numbers for each window light up in different
colors when someone joins/leaves a channel (blue), talks in a channel (white),
or calls your name in a channel (pink).)

(All the normal IRC commands work as expected, and so does tab-completion.)

(a note on /whois: if you have a PM window open for that person, the whois
information will appear in the PM window. Otherwise, it will appear in window
1.)

3. When you want to stop, do

/away <away message>

and then detatch from screen, which is

CTRL-a, d

(ctrl-a followed by d)

which will dump you in your normal sunjammer shell outside of screen.

Or you can just kill the terminal by typing

~.

or whatever.

When you log in again, restart the screen session with

screen -raAd

…and you’ll be back. If you then type

/away

…you’ll see all the messages sent to your nick in the meantime in window 1,
and you’ll be set to not-away.

4. More docs at http://www.irssi.org/documentation/startup
and http://quadpoint.org/articles/irssi
.

I mostly find irssi useful for being always-on all the time and having backlogs
of conversations that have happened while I’m away. It also means that anywhere
I have ssh, I have IRC.


Shell script ninja help needed: weekly test image downloading


Dear lazyweb: there must be a simple answer to this. I’m trying to write a shell script that a cron job can run every week to update our Sugar on a Stick (SoaS) test image repository. The ticket in question is Sugar Labs #2058. Longer explanation than usual given so those new to the dev/test/release cycle can follow along.

Basically, prostate SoaS is a Fedora Spin, stuff so we get nightly composes made here (as in, “Fedora automagically builds our .isos for us so we don’t have to”). In order to (we assume) save on disk space, the Fedora servers only store the latest nightly compose – once a new .iso is made, the old one is gone forever, bwahaha!

This is fantastic for developing, but not so much for testing. Expecting testers to keep up with daily builds is a bit much, and it’s putting a burden on people who are downloading them every day (possibly even getting into trouble with their ISP), so we decided to go with a weekly test cycle – each Thursday evening we’d designate the most recent image as the “image under test” and point everyone there. That way, developers would also know exactly what image people were finding bugs in each week.

Problem: in order to (we assume) save on disk space, the Fedora servers only store the latest nightly compose -  once a new .iso is made, the old  one is gone forever, bwahaha! So we need to grab the most recent image – which has a special naming – at that time and pull it down to the Sugar Labs servers so we have the files at http://download.sugarlabs.org/soas/test/ (We’re also storing the old test images so we can go back and forth between them Since the builds do contain their build date in their name, and we can’t predict ahead of time what the build date and time are, we don’t know the exact filename to pull.

So we’re basically looking for a shell script that will:

  1. Pull the latest iso and checksum from the SL servers
  2. Rename the checksum so it matches the datetime stamp of the iso (the checksum is currently called – rather unhelpfully – “CHECKSUM-i386″).
  3. Update the symlinks so that http://download.sugarlabs.org/soas/test/soas-i386-test-latest.iso and http://download.sugarlabs.org/soas/test/soas-i386-test-latest-checksum.sha point to the latest iso and checksum that were just downloaded.

This probably requires some sort of weird wildcard bash-fu that would take me multiple hours to inelegantly figure out, and someone else 5 minutes to write a one-liner to solve.

Can haz halp?


SLOBs discussion: what are the biggest issues in SL right now?


The Sugar Labs Oversight Board (SLOBs) has had trouble getting together on IRC recently because of everyone’s crazy schedule, information pills so today some of us got together in-channel and got through the list of outstanding topics as best we could. It wasn’t an official SLOBs meeting – with only myself, Tomeu, and Chris Ball, we lacked quorum and couldn’t make any official decisions – but we moved things forward as best we could, because these issues are pressing.

Remember, nothing says that anyone (you don’t have to be a SLOB!) can’t move things forward, SLOBs-fu is only needed for the final formal vote! The full log is available, and I’ve added it to the list of past logs while noting that it wasn’t an official SLOBs gathering, for clarity. Here’s what we covered:

  1. F11+0.88+XO-1.* as a SL project – Bernie had sent in a request on behalf of Paraguay Educa and Activity Central to make Fedora 11 with Sugar 0.88 builds for the XO-1 and XO-1.5 a new official project. It wasn’t clear to us what resources they needed; we pointed out that they could get infrastructure/hosting without being an official “SL project” (and indeed without asking SLOBs!) and asked what else they needed – trademark permission, etc? Tomeu brought up that SL projects were the ones that SL teams (Marketing, Design, Development, etc.) were expected to support, so it’s not clear that this would be the appropriate designation for the F11+0.88 builds – there may be a more appropriate upstream for the project to be under (Paraguay Edcua, Activity Central, OLPC, Fedora, etc.) and then SL could partner with that project instead of being the umbrella org for it.
  2. Ooo4Kids logo display request – Ooo4Kids asked if they could display our logo on their “partners” page, but we’re blocked by not being able to find the original text of the request for this. If you know where to find this, or who at Ooo4Kids to contact about it, please let us know!
  3. Trademark usage applications – A number of local labs have asked for permission to use the SL trademark, but again, we’re blocked by not having the original request text. If you’re from the Colombia, Paraguay Educa, Argentina, Chile, Peru, or DC Local Labs, please help us find your request!

Since all three of these are continuing discussions, and we’ll be continuing those discussions on-list, I’ve linked to those discussion threads from the agenda for next week. (The other two things on the list for next week are “Review of RM search” and “Motion and possible vote on Sugar certification,” – I am not sure what the latter means, so clarification would be great, what’s the motion we’re looking at?)

Question for all Sugar folks: what do YOU think the most pressing problems in our community are? That’s what SLOBs should be addressing – so please tell us what our biggest (non-code) bugs are.