The original idea was to have an other code fest somewhere after the PHP Quebec conference in March. While that CodeFest will still take place, we couldn’t wait that long and planned one for the week-end. Again, it was a huge success. Around 20 people showed up. We actually had name tags the first day because of the new unfamiliar faces. This time around, it was held at La Bande Passante.
During the last CodeFest, we all went there with OpenID in mind and a project to implement it in. This time around, there was a vague idea around Microformats and it took a while before everyone got started on their projects. I didn’t really get to see that part of the event as I was busy on a completely different agenda. Evan Prodromou and I had the objective on writing a converter from MediaWiki to TikiWiki. This was actually the idea that triggered the CodeFest in the first place, but the idea was too small to get many people contributing to it. Our project was nearly done by the end of the afternoon on Saturday. The code is in CVS and ready to be used.
It’s a good thing we did not spend too much time on it, because Sunday was all about Wiki-Translation. We used the opportunity of being all together to really kick-off the project and align priorities. Alain Désilets had the great idea of bringing post-it notes. We did a complete agile-like project launch starting from user stories to task prioritization. These are the steps we went through:
Naming movies we like and post them on the wall.
Apparently completely useless, but it did get us started and used to write stuff down and throw out ideas. I don’t know if it really was a mandatory warm-up, but the 5 minutes we spent on it was not much of a waste.
Identify use cases and small stories where translation could be useful.
In a matter of minutes, we came up with over 25 different stories, some similar to others, but showing different aspects and contexts. I really never expected we would get so much. I wish we could actually publish them, but most of the experience was oral and only a few words were ever written on paper as a reminder while we did it.
Regroup and categorize stories
This was actually a very hard part. What we soon realized was that we couldn’t simply draw a line or two to split them up. Two dimensional space was not enough to categorize those stories. Translation is way too much of a broad topic. Instead, we came up with dimensions to classify them. Divisions were minimalistic, but very easy to determine from a given story. (listed below)
Find concrete applications
Some of our stories were real, some were plausible fiction. Obviously, there is no way we can hit all targets, so we decided to narrow-down the objectives to our potential test sites. For each test site, we identified where they were located for each dimension. In the end, we selected a single site we should focus on to begin with.
The brainstorm was at it’s peak. I still don’t realize how it happened, but we ended up finding over 20 user roles for the test site. Of course, many were similar, but really, I never expected to fill a wall on this one.
Identify tasks and cross reference
With the roles in hand, we started identifying the tasks these users would perform. Again, we had tons of them. We made sure all roles had tasks and all tasks had roles and moved on. It was getting late, maybe we could have spent more time on this one.
This is the moment where we realized we had a whole lot of stuff missing. Trying to build workflows from our tasks made us realize that we had gaps to fill. We were able to split the tasks in 4 groups and put them in order with their dependencies… roughly. The end result is more of a guideline than an actual implementation plan, but it did align everyone on the project’s objectives.
These are the dimensions we came up with. Most of them are connected. We could probably reduce the set even more, but the rules are simple enough this way.
Amount of content consumers vs amount of content producers
This factor really indicates if the community is actively creating content or most of the content stays static.
Mandated vs non-mandated
This factor takes into account wether the effort is volunteer or you can actually expect work to get done by a certain date.
Document is an end in itself vs a way to achieve results
We had scenarios where wikis were used internally as a method of communication and others where it was only building up information (Wikipedia-style).
Translations must be aligned vs used in a synergistic way
For documentation, you really want all languages to have the same content, but in other contexts, you might want to skip some information or make it evolve differently, which is mostly the case where each version should keep cultural aspects.
Control is top-down vs organic
Is the content creation organized or will it just happen in some disorganized way?
Content quality is important vs draft sufficient for communication
It’s likely that a low-volume website with a minority using the translations will not spend tons of efforts translating. The translation may just be used as a way to propagate information quickly. It was proposed that only a summary of the text be translated. The foreign reader could, from the summary, determine if it’s worth the effort to try to understand the whole article.
For the Cross Lingual Wiki Engine Project, I think the CodeFest was really an important moment. I’m quite satisfied with the results we obtained from the brainstorm. Sadly, most of it is only in our heads. Very little could be written from it. The activity gave us perspective on the larger goals ahead of us, even if we decided to narrow-down the project for the first few iterations.
I only wish I could have spent more time looking into the microformats part of the CodeFest and meet the people working on it. I don’t really have any idea of what they achieved.
The next CodeFest will be after the PHP Quebec Conference and will most likely be an optimization workshop. Until then, CUSEC 2008 is only a few days away.