MDN/Doc Sprints/2010Q4

From MozillaWiki
Jump to: navigation, search

MDN Doc Sprint 2010 Q4

Goal: Create tutorials for web developers on using open web standards.

Dates: 9-11 October, 2010

Location: Mozilla office (Sat & Sun), Paris France; La Cantine (Mon)

Potential Topics

  • HTML5 (incl. video)
  • CSS3
  • JavaScript (esp. multithreading)
  • SVG
  • WebSockets
  • MathML

Some of Paul Rouget's demos could be used as a basis for a tutorial. That is, describe each of the parts that go into the demo, and how they fit together. Here are links to some of the demos:

Here are some examples of tutorials to use as inspiration:

Participant Profile

  • Familiar with at least one of the target topics.
  • Able to read code and then describe it in words.
  • Lives in Europe (for in-person participants).
  • Moderately fluent in English.
  • Preferably already active in the Mozilla community. However, topic expertise trumps this.

Schedule

8-Oct 
Everybody arrives; dinner together.
9-Oct 
Discuss agenda and plan; assign tasks; start working.
10-Oct 
More work on tutorials; dinner and bowling.
11-Oct 
Finish tutorials; assess and clean up. Mozilla Community dinner.
12-Oct 
Depart for home.

Logistics

Questions about logistics? Contact William Quiviger (wquiviger at mozilla dot com)

Sleep

Out-of-town visitors will be staying at the Hotel Ibis near Bastille (in the heart of Paris), a few metro stops away from the Paris office and from the Doc Sprint meeting room.

Ibis Paris Bastille Opéra,
15, Rue Breguet
75011 Paris
Tel :(+33)01.49.29.20.20
Fax :(+33)01.49.29.20.30
Map: http://bit.ly/creWLq
Nearest metro stop to go to the office: "Chemin Vert" (line 8)
Nearest metro stop: "Bréguet Sabin" (line 5)

NB: although the hotel room is pre-paid by Mozilla, you will be asked to leave your credit card number at the reception desk as a garantee in case of damages and/or extra expenses such as mini-bar items, room service etc.

Food

Breakfast is included with your hotel room. Lunch and dinner will be organized and paid for by Mozilla. Free snacks and drinks will be provided throughout the Doc Sprint.

Janet will send an email to tell you where and at what time to meet for an informal prep-meeting on Friday evening. NB: if you have special requests in terms of food, contact Janet or William!

Work

The Doc Sprint will take place on Saturday and Sunday at the Mozilla Paris office:

Mozilla Paris office:
28 Boulevard Poissonnière
75009 Paris
1st door code : 35A74
2nd door code : 61B35
1st floor, door on the left.
Metro : Grands Boulevards (line 8)
See map: http://bit.ly/aImBYV

The Doc Sprint will move to another place on Monday:

La Cantine
151 rue Montmartre, Passage des Panoramas
12 Galerie Montmartre
75002 Paris
Metro : Grands Boulevards (line 8)
See map: http://bit.ly/aImBYV

Transport

For non-Mozilla staff, please make sure to send William a scanned copy of your plane or train tickets and bus/metro/taxi receipts for the Doc Sprint and please fill out and return the following form: http://somethin-else.org/public/Mozilla_EU_expense_report_template.ods

We'll process a full reimbursement shortly after the Doc Sprint is over.

NB: When you arrive at your hotel and have checked-in, make sure to ask the reception desk for your 10 metro tickets. William will give the reception desk your tickets beforehand. If they don't have them, ask them to call him. Other solution is to buy your tickets yourself and get reimbursed.


Getting to/from the Mozilla office from your hotel

To office:
Walk to "Chemin Vert" metro station, use 1 metro ticket to get past turnstile and take metro line 8 towards "Balard" then get off at "Grand Boulevards". Once there, make sure to take exit #1 ("Sortie" in French). Follow the exit and once you're up the stairs, just walk straight on boulevard poissonnière for 50 feet and you're there - the ride will take you 7 min and door to door from hotel to office, no longer than 20 min (if you don't get lost!)

From office:
Walk to "Grand Boulevards" metro station, use 1 metro ticket to get past turnstile and take metro line 8 towards "Creteil-Prefecture" then get off at "Chemin Vert"

Se map: http://bit.ly/aImBYV

Getting to hotel from CDG airport

Taxi: it will cost you 65 EUR and it will take you 30min-50min depending on traffic.

Train: it will cost you less than 20 EUR for a return ticket and it will take you 50 min. You can buy a ticket at an automatic machine (only accepts EU credit cards though) or at a human ticket counter. From the airport, take the "RER B" train going towards Paris and get off at "Gare du Nord" then take the metro line 5 that goes towards "Place d'Italie" and get off at "Breguet Sabin". Then it's a 4 min walk to the hotel. See map: http://bit.ly/aImBYV

If want to reduce both your carbon footprint and your expenses, take the train.

Results

The Open Web Doc Sprint was held as planned, on October 9 to 11, 2010.

Participants

The community participants in the sprint comprised two previous MDN contributors, Florian Scholz and Jean-Yves Perrier, and two who had not previously contributed, Sebastian Perez-Vasseur and David Bruant. Florian and Jean-Yves continue to be active contributors to MDN, and also participate in bi-weekly contributors meetings via IRC. Following the doc sprint, David Bruant also participated in the Mozilla Drumbeat Festival in November 2010. Florian, Jean-Yves, and Sebastian were invited based on previous contacts; David volunteered in response to a Hack post a week before the event. One additional person volunteered to participate remotely, in response to the same blog post, but never made contact during the sprint.

This doc sprint was intentionally kept small, since this was the first event of its type that we've tried. For future events, broader participation should be pursued, through earlier and wider publicity of the event.

Participants gave feedback that the sprint was a valuable experience for meeting Mozilla community members, and to have both technical and informal discussions.

Schedule

Three days seemed to work well, in terms of balancing having enough time to focus and produce results versus taking time away from participants' lives. It would be possible to do a two-day or one-day sprint, but there should be proportionately more participants for shorter sprints.

There were activities planned for all of the evenings of the event, but we ended up dispersing on Sunday night, and letting participants have time to themselves. This worked out to be a better plan than non-stop activity and "togetherness". Folks were able to return on Monday feeling refreshed and ready for another day of doc work.

Content

The work accomplished is linked from a Hacks blog post.

The original plan for the sprint was to produce tutorials related to open web standards (c.f. #Potential_Topics). The actual topics produced were determined by participants' interests and knowledge, so only some of them relate to open standards or tutorials. Everything written is a valuable contribution to MDN, but the focus of the sprint was not maintained.

For future events, some possible ways to keep more of a topical focus would be:

  • Foster discussion/brainstorming among the participants ahead of time about what to write about.
  • Provide examples and templates of the types of documents, so participants are not starting from scratch.
  • Ask for commitments regarding who will write what on the list of brainstormed topics.

Process

The process during the sprint was very informal: At the beginning of the sprint, each person talked about what they planned to do during the sprint; each subsequent day, we talked about what we had accomplished and still needed to do. Towards the end of the last day, we summarized and showed off what we had done.

Some suggestions from participants on improving the process:

  • Have metrics such as number of documents or topics planned and accomplished, and review them each day.
  • Have 1-2 hour group activities like brainstorming or games that lead to doc writing while having fun. A big whiteboard might be good for this.
  • Try to document difficult stuff when there are experts there to help you.
  • There was not much teamwork because everyone was working on something different. IRC was a good tool to ask questions in public, so that everyone could have the answers if they were interested, but not be interrupted if they weren't.

Tools

The tools used were the standard toolset for MDN: the Deki-based wiki and IRC. David Bruant gave the following specific feedback on the wiki:

We've already discussed this point with Sheppy and Janet. The tool, even if currently fitting the goal, has quite terrible features. I have been told that you're planning on writing another one. I would be interested in following if not participating in the design phase of the tool. Who are the people in charge? Is there some doc or preliminary work around that project? Sources already?

I had began drafting something for a wiki user interface and I really don't have the time to finish/polish it, so I will just give you my different sources of inspiration and ideas : As concluded in this excellent article (http://mozillalabs.com/conceptseries/2010/08/16/crowdsourcing-project-summary-of-best-practices/), one of the most important thing to get people involved in a community project is having a "low barrier to entry". And, what is said about wikipedia is particularly relevant : "anyone can edit almost anything. In fact, the biggest barrier to entry for Wikipedia is its editing tools which many have criticized as un-user-friendly".

To address that, web browsers have all they need to write an "inline" text editor : the contenteditable attribute (https://developer.mozilla.org/en/DOM/element.contentEditable) ! When you want to edit a wiki page, there should be no need for going in another page with an edit interface and there should be no need for loading an iframe. Editing could be done this way:

  • Perform a double click on any section of the wiki article.
  • A discrete popup opens up to ask for edition intention confirmation. (This is necessary to avoid unexpected edits)

The only small problem I have found with this is that on some OS and/or browsers, double click might already "mean something". For instance, on Ubuntu with Firefox, I use double-click on words to select them. This is the reason why the popup should be discrete and preferably out of the article content.

  • Edit (and there is no any better WYSIWYG since you're typing directly in the web page).
  • Do Ctrl+S to save (prevent default behavior)

This is a light process, nothing needs to be loaded. The only unsolved issues being : how to add/remove a section? Obvisously, an HTML source mode would be nice. About the markup, I've been following an interesting discussion about headings:

The main idea being that with HTML5 new elements (article, section), a markup like 

<section>
<h1>Header</h1>
<section>
<h1>Subheader</h1>
<p></p>
</section>
</section>

could be prefered to : 

<h1>Header</h1>
<h2>Subheader</h2>
<p></p>

I tend to agree with the immediate benefit that you never have the problem of scrolling up thinking (where am I? should I write an h3 or h4 now?) About the table of content, there might be interesting things to do with a fixed proportional table of content : http://www.jankoatwarpspeed.com/post/2009/08/20/Table-of-contents-using-jQuery.aspx http://www.jankoatwarpspeed.com/examples/table-of-contents/

I think all what I've thought about is here. Just a last point. During my investigation on contenteditable, I've found an interesting blog post (http://accessgarage.wordpress.com/2009/05/08/how-to-hack-your-app-to-make-contenteditable-work/) which seems to point that the Firefox contenteditable implementation has some problems. Though, they seem to find their solutions. Anyway, if they are still present in Firefox 4, having MDC using contenteditable would be a good occasion to fix them ;-)

Retrieved from "https://wiki.mozilla.org/index.php?title=MDN/Doc_Sprints/2010Q4&oldid=300637"