Cheer Xiao

E-Mail

<xiaqqaix AT gmail DOT com>

Alternate Contact

(mobile) +8618210231602

Homepage/blog/wiki URL

http://wiki.tuna.tsinghua.edu.cn/xiaq (Yes, a moin site :D)

Country (born / living in)

P.R. China

Academic experience

Undergraduate at Department of Automation, Tsinghua University, P.R. China

Your current occupation

Student

Software projects you have already participated in

• Roundup (project homepage, code repository), a lightweight, flexible issue tracker, written in Python and BSD-licensed. It is the issue tracker used by python.org (link). I submitted a series of patches, all accepted (some with amendments).

  • Preliminary Chameleon templating engine support (Git commit)

  • Fixing an extension mechanism - loading TemplatingUtils class in interfaces.py in issue tracker home directory to make Python functions available in the templating environment (Git commit 1, Git commit 2)

  • Several random cleanups (Git commit 1, Git commit 2, Git commit 3, Git commit 4)

  • Simplified Chinese translation update (Git commit)

  • I have more work in progress for Roundup...

• Fcitx (project homepage, code repository 1 and 2), a highly modular input method framework, written in C, GPL-licensed.

  • I was the primary author of fcitx-m17n (code repository), fcitx's bridge to m17n input method framework, also programmed in C. This is one of the first steps for fcitx to become an international IME framework; previously it was used for Chinese exclusively.

Experience Level

I don't have much actual experience with coding, but I'm still confident about my general programming skill. The following estimations contain hours of meditation on algorithms and designing besides actually typing code and debugging. :)

Experience with google summer of code

Never before

Experience in coding in general

started 2005, 1000 hours (most of which was spent on Olympiad of Informatics)

Experience in Python coding

started 2006, 200 hours

Experience in HTML

started 2008, 60 hours

Experience in CSS

started 2008, 60 hours

Experience in Javascript

started 2009, 40 hours

Your favourite programming language(s), best first

Python, Lua, golang, C

Tools you use for development

Vim, ctags, zsh (if that counts as a development tool), Firebug, Git

Did you already do full day work (8h/5d) over some weeks on some software project yet?

N

If not, is your motivation good enough that you think you can do that for MoinMoin?

Y

Project I apply for and my ideas for them

I'm applying for the issue tracker project, as listed at GoogleSoc2012/InitialProjectIdeas#Issue_tracker.

Issue tracker

What needs to be done and how

• Issue trackers emphasize the workflow to enhance productivity. By contrary, wikis focus on solidified knowledge. Therefore the UI needs to be rendered differently - there needs to be a UI with nice forms to edit an issue's metadata, to add comments etc., instead of requiring the user to edit the underlying markup by hand (+modify view). Also the edit history (when a comment was added, by whom, etc.) needs to be shown in a streamlined way.

  • The specialized UI can be implemented by (say) adding an +issue view to /apps/frontend/views.py. There are already quite some views there that render in different ways - +show, +dom, +indexable, +highlight, etc.. They can be factored out into a category of rendering views and split from /apps/frontend/views.py. Ideally +issue will then be implemented as a rendering view plugin, but the new plugin system hasn't been implemented yet. Still, +issue will be implemented loosely-coupled with existing view codes, so that it can be taken out to form a plugin later.

  • There needs to be a way to differentiate an issue from an ordinary wiki page. Mimetypes (contenttype metadata key) probably won't do, since issues may take different mimetypes (text/x.moin.wiki, text/x.moin.creole, etc.) depending on the underlying markup language used. Another metadata key like contentsemantics seems reasonable. Possible values are plain for "ordinary" items, issue for issues, etc. (Nomenclature not final.) This is somehow orthogonal to contenttype, but no fully: eg. both text/x.moin.wiki and text/x.moin.creole mimetyped items may take plain or issue as contentsemantics, but image/png item is always plain. The decision remains open.

    • Employing the additional contentsemantics property, user pages can contain both user homepage (wiki markup) and user profiles. In moin1 only user homepage is possible; in current moin2 only user profile is possible since user profiles takes a special contenttype application/x.moin.userprofile, preventing wiki markup types to be specified.

• Regarding the way to organize comments of an issue: All comments in one item (flat issue); or each comment as an item, with an issue aggregating them (threaded issue). On the UI it should be possible to add comments on the +issue view directly, instead of using +modify to modify wiki markup source, whichever structure is to be implemented.

  • Flat issues will be implemented first, as it is simpler. Threaded issues may be implemented later, possibly as an optional feature.

  • The commenting widget is somehow similar to the <<PageComment()>> extension and its descendants in moin1.

• The index is used heavily in an issue tracker. In fact, most issue tracker software provides some form of an index as the tracker homepage. The issue index can be worked on adding missing features to the +index view:

  • Extensive sorting and filtering will be supported; currently items are always sorted in alphabetical order by titles, and only content type filtering is supported.
  • Currently only the title field of items is displayed; it should be possible to control which properties are shown on the UI.
  • Predefined queries ("all open issues", "all issues assigned to me", etc.) should be supported.

• Issues tend to have lots of metadata keys. Thus the schema (schema = the set of keys and possible values for each key) mechanism needs to be enhanced, and a decent metadata editor needs to be implemented.

  • Currently, possible metadata keys live in constants/keys.py, and codes specifying value constraints live in storage/middleware/validation.py. They can be centralized into Flatland form classes. The Flatland form class may also contain hints for the metadata editor (the placement of properties, etc.).

  • Provided that the issue schema is represented as a Flatland form, The metadata editor can be implemented mostly in Jinja, similar to the widget prototype presented in Flatland doc. The metadata editor can also be used by the +modify view to replace current raw json editor. (Editing metadata as raw json will still be possible.)

• It is desirable to have the schema customizable on a site basis.
  • Some issue trackers offer a fixed set of issue property fields, which harms flexibility. Some offer complex and customizable schema. Instead, I will do it "small and customizable" - the schema will be created from scratch, by the issue tracker administrator.

  • A predefined Flatland form Issue with an essential set of issue properties is offered. The administrator may customize the schema by subclassing Issue.

  • It will be more difficult to implement a metadata editor that supports arbitrary schema.
  • Extra feature. Core features will be implemented first.
• Issue trackers may require very fine-grained permissions. As an example, only members in group X may close an issue, and only members in group Y may assign other people to an issue. This will require ACLs based on the metadata key, instead of the whole item.

  • Finer-grained ACLs is a general mechanism, independent of the issue tracker proposal.

  • It can also be used by users to decide which part of their profiles is visible to others.
  • Extra feature. Core features will be implemented first.

Rough plan, deliverables

• I will be pushing code to https://bitbucket.org/xiaq/moin2/. In its final form, changes will be sent as a set of incremental patches against the default branch of official repository.

• Midterm goal:
  1. The metadata editor is able to present current values, modify values, and validate inputs. CSRF prevention can be easily added later.
  2. The commenting widget gets implemented to support flat issues.

  3. Building on top of the two components above, the +issue view is complete. It is possible to create, view and modify a single issue through a conventional issue tracker UI.

• Final term goal:
  1. The issue index page functions correctly. It is possible to do filtering and searching directly from the issue index page.

  2. The metadata editor gets ported to the +modify view.

  3. (Optional) It is possible to customize the issue schema on a site basis. The metadata editor is flexible enough to handle reasonably arbitrary schema.

Why I am best suited for the project

• As mentioned above, I had experience administrating, customizing and developing Roundup issue tracker. Familiarity with another mature issue tracker would be very valuable for the project:

  • I have an understanding of the functionalities that an issue tracker has to offer, so that the goal is clear in the first place;
  • Roundup is also written in Python, so designs can be borrowed where appropriate.
• I have gone through the docs of Flask, Jinja2 and Flatland; I have also been studying moin2's current codebase. I'm well prepared.

Other obligations

• University stuff (attending lectures, exams, etc.)
  • Exam weeks: 6.11 - 6.24 (I will have 4 tests)

EOF