Amhorcher

Technical Competency Summary

1. Servers and Web Servers: Unix/Linux/Ubuntu Apache, IIS, Windows Server
2. Web 2.0: Blogging Podcasting Videocasting
3. Content Management: Sharepoint EMC Documentum Open Text Drupal
4. Workstation: Word, Excel, Powerpoint Visual Studio
5. Mobile devices: iOS (iPhone), Blackberry Android, ebook readers
6. Programming: PHP, HTML, CSS, VB, Unix scripting, Some java
7. Project Management (Six Sigma)
8. SAP: KM,, PM, EHS, HR Relational
9. Database: MySQL, Oracle, Sybase , Access

IRC: Amh

Identity

Name:Ann-Marie Horcher
Email:horcheram@gmail.com
Project title:MediaWiki authoring interface for Docbook content

Contact/working info

Timezone:Eastern
Typical working hours:varies with the needs of my mentor. Normally 7-10 AM, 1-6 PM
IRC or IM networks/handle(s):amh

Project summary

Mediawiki is an easy way for remote authors to collaborate on content. The content editor is easy to use, and resolves conflicts. The authors can get opinions and edits easily from other sources as needed. Occasionally Mediawiki projects grow into content that would be better handle as print. One of the most popular formats for creating documentation, such as the OReilly series, is the Docbook format. Docbook is a series of tags that can format data into sections, chapters, and books. It also allows glossaries, indexes, and table of contents. Mediawiki content is also formatted by a series of tags.

A converter from Mediawiki to Docbook would allow the ease of editing and collaborating in Mediawiki to be connected to the the printing and formatting control of Docbook. It would be an opportunity to use two open source formats for what they do best. The content from Mediawiki on occasion need to distributed in contexts. The Docbook gateway provides access to some very popular formats, such as ebook and PDF through already available XLST transformations. An option to have electronic-based, but offline portable copies of MediaWiki content is valuable in the case of personal, civic, and natural disasters. Docbook lacks an easy entry level editor that MediaWiki could easily become.

About you

Currently I am a PhD student in Information Systems. I have always looked for an easier way to do things from organizing my sock drawer to redesignng a business process. My impatience with misusing people to do what a machine does better leads me to keep looking for a better way.

When authoring documentation on a project the ease of MediaWiki is a amazing. The purpose of a computer interface is to enable the result, not bog the user in learning the peculiarities of the software. MediaWiki achieves that for collaboration, and organizes the result. The lack of barrier is key in the early stages of documentation because many technically competent people hate documentation. If it was easier to write and collaborate from the beginning, it would be less likely to be avoided, or given short shrift at project close.

Unfortunately when first writing documentation the final destination may not be set. Mediawiki provides a usable version online, but not much formatting for alternate versions. When preparing documentation for a large research project I found the Docbook format. It was great for transforming the content, but there was no easy way to share authoring. The Docbook editors (at least the free ones) had a high usability barrier to the novice.

One content authoring tool can't do it all for everyone. The most valuable content authoring tools are those that provide a bridge to other tools that provide additional functionality. This export is an example of that.

Deliverables

It should be possible to break down your project into some bullet points describing particular features or milestones which can be reached individually. Consider that we may wish to roll out the system for testing when at an intermediate stage of completion, and that time estimates might vary, leaving you with more time than you expected or (more likely) a lot less -- some features can be pushed back if you end up short.

Required deliverables

Map of Mediawiki tags to Docbook tags (useful for future extensions of the project) Script/Plug-in to export MediaWiki content (based on current exporters that connect to Word) Script to reformat Mediawiki tags to Docbook tags Distributable package of all three for SourceForge

If time permits

Transformation of Mediawiki to ebook format through Docbook

Project schedule

Week 1-3 May 23-June 12 Preparation Build offline development environment for Docbook and Mediawiwki, choose wikis to use for sample set for development, pull copy of mediwiki code to github account, get list of Mediawiki tags and definitions, map to docbook tags, submit to Docbook experts for approval of mapping. (First deliverable) Determine best approach for exporting Mediawiki content using both word exporters and input from the Mediawiki community.

Also set up communications with mentors and Mediawiki communication, make agreements about responsiveness and where to respons, and the channel used (email\IRC\other)

Start project documentation to use as one of the test wikis

Week 4-7 June 13-July 11 Development While waiting for the list of tags to be vetted, begin scripts. - export plugin/script to get a desired segment of Mediawiki content (including getting all sub-pages) - Script to read Mediawiki/Docbook map file to new tags and produce new version of content - test scripts and debug - Look for integration point into Mediawiki (based on feedback from mentor and community) - Recruit testing group - Update project documentation and test in the script - Move testing version to github - fill out midterm evaluations

Week 8-11 July 12 - Aug 1 - resolve bugs, apply feedback from test group - Continue documentation in mediawiki, adding images and greater complexity - Release versions of code to github - Run end to end tests

Week 12-14 Aug 2- - Prepare code for release to general community - complete documentation - fix unantcipated issues - work on non-required deliverables

Pencils Down Aug 15 - Make all code works

Participation

The Teambox software is a handy project communication venue. It was used by the Spanish Team who won the World Cup to plan their actions and strategies. Teambox allows a request to go out to a group for feedback. It also allows the opportunity to post links, and track a discusssion. I normally monitor the mailing list of the projects to see what else

As question comes up, I would post and then move on to another portion of the project. I would let my mentor and responders know which questions are obstacles to further progress on the project. Normally I would submit a weekly of progress, what issues have arisen, and whether there is an impact on the schedule.

Past open source experience

GSOC Summer of Code 2010 for the Docbook organization - converter from Docbook format to ebook. Click http://www.youtube.com/watch?v=Z9jwHe4FAZkhere to see a Youtube video on the project.

Also featured in the Google Opensource BlogDrupal implementation

configure and install local Drupal repository for SVSU. MySQL/PHP/Apache - applications built on the XAMPP stack to support analysis of data for my dissertation

Any other info

If there's other relevant information -- UI mockups, references to related projects, a link to your proof of concept code, whatever. There are no specific requirements, but we love to see people who love what they're doing. Show us you're excited about this project and have an interest in the background and are considering how best to make your idea work.

           «««««««««««««««««««««««««««««««««««««««««««««««««   ≤  ≥  »»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»»

See also

Remove for an edit