Late as usual! MDN 2.4.5 bug list and backlog.
KumaScript is in! (Though it's not available on stage9 yet.)
Migrations are running on stage9
Check the MDN 2.5 backlog for what we're pushing next!
MDN 2.4 bug list. This was our first 1-week sprint and release, so there's not as much to report.
Nothing shipped, but Les filed the master bug for KumaScript - our replacement for DekiScript.
Fixed lots of little bugs and enabled BrowserID for French, German, Spanish, Polish, and Chinese locales.
MDN 2.4.5 sprint backlog.
KumaScript lives and I ran it successfully on my local environment!
Syntax highlighting for code samples - both new and migrated
Profile doc activity feed switched to Kuma
- Some bugs
So, wiki work continues at a good clip and our process seems to be going well. We're changing our standup time to 10am PT since most of the team is CT or ET now.
UPDATED: New screenshot with html filetype! Thanks Screwtape for the tip in the comments!
Yes, it's possible! If you're like me you want to spend as much time in vim as possible. While I appreciate CKEditor on MDN, I personally prefer to edit text in vim, and I think many developers might agree. And since MDN should include content written by developers for developers, here's a way to edit your favorite web developer docs (that would be MDN), using vim. (In my case, MacVim)
- Install the It's All Text Firefox addon.
- Go to the IAT preferences
- set your editor to vim (MacVim.app in my case)
- set your hotkey. (alt+command+e in my case, now that I'm used to Firefox Dev Tools "Inspect" and "Console" keyboard hotkeys)
- Go to the MDN article you want to edit. (Apps/Getting Started in my case)
- Click Edit (duh)
- Click Source
- Type your hotkey!
- Drink beer and edit away!*
* groovecoder is not responsible for whatever Sheppy might do to you if you actually edit MDN while intoxicated.
Note: For MacVim you may need to set the "After last window closes: Quit MacVim" preference so it puts you right back to Firefox when you :wq.
Released February 28th. We are moving to weekly releases on MDN so these posts are hard to keep up. I will probably start combining releases. And I'm just going to link to the MDN 2.3 bug list instead of linking individual bugs.
migrate tags from MindTouch to Kuma
(Re-)enable tag display and editing
remove extra redirect for locales
verify code samples work post-migration
fix login infinite redirect bug
- HTML5 & Apps MWC pages
Paul and Craig cranked out the new HTML5 and Apps landing pages in time for MWC
While Paul was with us he created ScrumBugs! I love it! I always appreciated the way we did Agile/Scrum/XP/whatever at SourceForge.net, and I've been
forcing pushing for Mozilla WebDev to adopt some of the same practices. And I just really like pretty graphs! Can you tell?!
MDN 2.4 & 2.4.5
We're calling our first weekly sprints 2.4 and 2.4.5, but I think next we'll just move to 2.5, 2.6, ... until we all meet up in New York for MDNYC. At that point we'll probably abandon bugzilla milestones and just use the whiteboard to organize bugs into sprints based on release dates. Until then, here's what we're working on for 2.4 and 2.4.5.
Hopefully killing all the remaining BrowserID bugs so we can concentrate on wiki
Les is rocking lots of KumaScript work
Migrate file attachments
Wiki code syntax highlighting
Refine UI for tag editing
Activate continuous migration on staging server for MDN doc community
bug 721171 to draw Sign in buttons with progressive enhancement - should hopefully fix our search results snippets too! ><
bug 719945 to link to browserid on the demo submit page
- MindTouch wiki migration
prepare for localized page migration (bug 717380)
scripting architecture (bug 715253)
We're doing better at keeping away from big new features while we try to work on the wiki migration, so there's no big item in today's release notes.
- More BrowserID cleanup
bug 715723 was really annoying - Sign in was broken from wiki pages
bug 715811 should help users who've forgotten which email address they use on MDN
- MindTouch wiki migration
James did a thorough job on bug 710734 to expand the markup allowed in kuma
Les did some more great working discovering all MindTouch namespace pages (bug 710753) and script template usage (bug 714804)
Craig fixed up a bunch of CSS issues we've discovered as we migrate real content (bug 710737)
Wow, that's how much of a non-event a "2.0" product release is these days. I forgot to publish this when we pushed 2.0. Might as well publish before our 2.1 push today.
- Set up 'master' and 'next' branches and corresponding stage servers on allizom.org (bug 710747)
- Wiki content migration & work
Small sprint this time, but Les made some great progress on our wiki migration. I'm forcing myself to do a migration script bug this sprint so I learn enough of that code to follow his architecture and contribute what I can.
- Set up 'master' and 'next' branches and corresponding stage servers on allizom.org
- Wiki content migration & work
A few years ago I pushed hard for OpenID on SourceForge.net. OpenID was and is a noble project. But now I can tell some big advantages of BrowserID over OpenID:
- It feels like an identity. I cognitively associate my online identity with my email, and BrowserID is a verified-email protocol. When I saw my email in the BrowserID login dialog on MDN, I already understand that I'm logging in - much more-so than an empty 'URL' input box.
- The site already knows you. As a site owner, we already have email addresses for our users. So when you sign in with BrowserID, we don't have to say "Now sign in with your existing account to merge your new identity with your existing" the way we did with OpenID. We know you own that email, so we log you into the account with that email address - simple.
- Changing email is easy. Craig and I fretted for a whole hour or so over how to let users change their email address with BrowserID, but we were over-thinking it. Since BrowserID is effectively a streamlined "verify your email" dance, we simply point our "Change email" links to our sign-in page. If you're already signed in, and you sign in with a new verified email address, we simply update your email. BrowserID has already done the whole verify-your-email-address dance.
- No lock-in. We get a verified email address from BrowserID, so we can register users in django with set_unusable_password(). But if we ever drop BrowserID (oh noes!), we have a verified email address. So we can initiate an email-based password reset flow for users. In addition, any site can run their own verification service so they don't need to call Mozilla's BrowserID at all.
- Privacy. Finally, BrowserID is a user-centric identity system. This really hit me when I watched Ben's Deeper Look at BrowserID video. Especially when BrowserID is implemented in other platforms, Mozilla doesn't sit between you and the sites or services you use. A primary authority can issue identity certificates to your agent, and you present those certificates to other parties for authentication. "This triangle is never closed."
All-in-all, it was much simpler and much more intuitive to implement BrowserID on MDN than it was to implement OpenID on SourceForge. The Mozilla Identity team has built an awesome product, and Les integrated django-browserid with his trademark pace and effectiveness. BrowserID is great for the whole web - it will help us regain control of our online identities. It's worth repeating, "the people I work with are built of brains and heart" - it's another great day for Mozillians and for the web.
/me is so proud
Since Jay will be gone, John is re-joining us part-time to do some product management along with folks from the Developer Engagement team until we hire a dedicated PM. Until that happens, we're going to work hard on the wiki migration and we'll only add features if they are high priority - like Apps, BrowserID, mobile, etc.
We released MDN 1.7 today. Included in this release:
- Switch auth from MindTouch to django (big bug 674635)
The major themes of MDN 1.8 are:
- Merge our separate mdn & wiki branches so we can develop and deploy both with a sane release process.
It also lets run the new wiki on the production site, controlled by waffle, so we can get feedback from MDN users on the new wiki.
- Clean up and polish the django auth.
- Define UX and mockups for BrowserID.
- Continue to support the Apps developer launch on MDN.
It's gonna be the future soon
Jay is leaving Mozilla! I'm going to miss him and his war stories from the good ol' days of Netscape. He brought a lot of insight and perspective to MDN and drove the efforts to make it more than "just" a documentation wiki. Until someone else takes over product management, we're going to put our heads down to work on the big components of the MindTouch-django wiki migration:
- Migrate MindTouch wiki data.
It's nice that MindTouch stores HTML and our django wiki also stores HTML. Much better than having to parse and translate wiki markup.
- Implement an alternative to DekiScript
I'll probably run product
management interference for any urgent MDN features (e.g., apps) until we have a dedicated product manager.
Right now James and Les and I are in Toronto with #sumo and #sumodev talking about the future of the newly-amalgamating "Platforms" Webdev team. We want to open MDN, SUMO, Mozillians.org, and Input sites as community "platforms" over the next year. Stay tuned for more ...