Contents
Project Ideas for Google Summer of Code 2011
MoinMoin project will take part in Google SOC 2011.
Mentors and students may announce their interest in some specific project(s), maybe this helps us to avoid collisions.
Of course each student may apply for multiple projects - as well as multiple students may apply for the same/similar project.
Only the stuff that gets submitted via Melange will count in the end.
General
These are some initial project ideas that should guide students when writing an application for GoogleSoc2011 (see the disclaimer there).
These ideas are very brief - we know that and we do that on purpose, because we expect from you that you get active:
- use moin
- look into the moin code
- talk to moin developers and other moin users
- work out a more detailled project proposal before writing your application.
If your application is as brief as the ideas listed below, we see that you did not work on it enough.
Mentoring
Mentoring will be done by the people listed on MentorGroup - these are usually long term MoinMoin developers.
Get in contact with us!
If you consider doing Summer of Code with us, get in contact with us early! Best way is IRC, see MoinMoinChat for details.
Required skills
We require good Python skills for all projects, except otherwise noted.
We'll help you with improving your Python (and other) skills, but there should be a good base to build on.
MoinMoin versions
MoinMoin 2.0 (short: moin2, mm2, m2) is our current development focus, we're doing heavy changes there about how moin works and what it is able to do. Top priority for moin2 is getting a usable wiki with basic functionality.
MoinMoin 1.9 (short: moin1) is our latest stable release (and the last 1.x release), no big core code changes are wanted there, thus no SOC project. Please note that this is good for you, the moin2 code base is cleaner.
Project Ideas (moin2 based)
We want to release moin2 in 2011, so we shall concentrate on release critical stuff and not do not release critical stuff.
Search/Indexing
Improve storage indexing, improve sqlalchemy backend
- improve item metadata indexing (requires: good SQLalchemy skills)
- item metadata/data search / "select"-style
- SQLalchemy backend - improve its performance and resource usage, more testing (requires: good SQLalchemy skills)
- UUID vs. names
Students interested:
Mentors interested: ThomasWaldmann, BastianBlank, AlexanderSchremmer
Supporters:
Search Engine support, Query parsing
We currently have no search functionality for items.
- implement a similiar query based search mechanism as we had in 1.x
- xappy/xapian? whoosh? other?
- fuzzy search / stemming / full text search
- tests
- documentation
Students interested: MichaelMayorov
Mentors interested: ThomasWaldmann, AndrewGrigorev, (ReimarBauer), AlexanderSchremmer
Supporters:
DOM based format transformations
Moin2 uses an internal "moin-DOM" to represent a document in a tree-structure. This is used as intermediate format for all kinds of input and output formats.
Requires: experience with tree representations, XML, elementtree (emeraldtree) plus the input/output formats mentioned below.
Project: Improve DOM converters
We have quite a lot of DOM converters, but they need improvement:
- they still have issues
- they are not complete
- they do not roundtrip
- failing tests, missing tests
- documentation
- maybe support for section editing?
add line numbers to DOM for support of http://moinmo.in/FeatureRequests/AutoScrollingTheEditorTextArea#Moin_2.0_Thoughts
Students interested:
Mentors interested: BastianBlank
Supporters:
text converter
Our text converter should be compatible to sphinx text
- What "text converter"? Sphinx uses rst as input format, do you mean that when saying "sphinx make text"?
- Yes, I think we should produce the same output text.
This idea needs a better description, it is still rather unclear what it is about exactly, what the scope and what the goal is.
User interface
Jinja2/Flatland widgets, Forms
We use Jinja2 for templating and flatland for form data feeding, extracting, validating.
We need widgets supporting all data types we use for revision metadata and for user settings.
Metadata editing and all user settings should have nice forms and good validation in the end.
Maybe metadata view could also use (disabled) forms, instead of showing json?
Students interested:
Mentors interested: Jason Kirtland (flatland project), ThomasWaldmann, AlexanderSchremmer
UI improvements
EasyToDo/make subitems theme widget with editor support + followup task with drag & drop support
improved history view (was: RecentChanges)
- simple history view (like misc. other wikis offer it, similarly how it is currently implemented in moin2)
- optimized history view (like in moin 1.9)
- "moin annotate" - show who changed what, line by line, colours?
- inline diff
- create a new view for getting all items a user has contributed too
Mediawiki-like Theme
Implement a theme that is similar to mediawiki default theme and gives a well-structured, consistent UI for moin2.
- requires: UI designs skills, usability skills, artistic skills, html/css/js/jinja2
Students interested:
Mentors interested: ReimarBauer, MarkusMajer (maybe, I need more looks on the new themeing engine myself and some tests)
Tests
py.test 2.0
Reimplement our tests for py.test 2.0. Improve test coverage. Do a sanity check on the tests. Rewrite tests.
Doesnt sound large enough for GSOC to me. -- AlexanderSchremmer 2011-03-28 20:50:27
- we have a lot of tests and the current test infrastructure is problematic. so fixing it, rewriting lots of tests will take some time.
Students interested:
Mentors interested: ThomasWaldmann
Plugin system
The moin1 plugin system is not powerful enough and too complicated. Design and implement new one for moin2.
See also PluginConceptOverhaul
Take a look on trac plugin system (http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture)
- Don't forget about internationalization and localization (current i18n implementation has many pitfalls, forcing i18n-aware developers to implement all i18n/l10n stuff in their own plugins from scratch)
Requires: experience with python plugin systems and software design / plugin architecture.
Note: this needs either us doing the design ASAP or a student jumping on it well before the SOC process (we maybe don't want to spend half of SOC for design discussions).
May be we can use yapsy. Example with some of the cli scripts. Next is to check if that ascii file could be ommitted. Or if it is usefull for something else.
- The extension could be changed by setting plugin_info_ext="moin"
From the presentation.rst of yapsy
The plugin info file gathers, as its name suggests, some basic information about the plugin. On one hand it gives crucial information needed to be able to load the plugin. On the other hand it provided some documentation like information like the plugin author's name and a short description fo the plugin functionality. Here is an example of what such a file should contain:: [Core] Name = Simple Plugin Module = SimplePlugin [Documentation] Author = Thibauld Version = 0.1 Website = http://mathbench.sourceforge.net Description = A simple plugin usefull for basic testing
Students interested:
Mentors interested: ThomasWaldmann, BastianBlank, AlexanderSchremmer
TODO
ideas on page EasyToDo - lots of stuff there - extract the not-so-easy ones, that could make a SOC project.
Misc. part-time Projects
pygments supported text format -> DOM (there is some code already, needs further improvements)
DOM -> SVG (can be used by svg-edit, is rendered by any modern browser, can be converted to various formats)
- XSL-FO is more adequate here, it is a page oriented output format
- migration tool from twikidraw format to svg (compatible to svg-edit)
- improving migration from moin 1.9 to moin2
Students interested:
Mentors interested: ReimarBauer
Inspiration
Just some buzzwords, be creative.
- unify macros and parsers
... TODO ...
You can have a look at all the FeatureRequests that are already stored in this wiki. Some of them might be a good inspiration for a SOC application.
Your idea!
If you have a great own idea for moin, that is not listed above, don't hesitate to apply with it.
Advice for own ideas:
- maybe check on the wiki if the idea has been discussed already and what the outcome was (some stuff sounds great first, but doesn't withstand a deeper look)
- check if your idea is rather generally useful for a wiki or if it is just something YOU (or very few people) need
- if you discuss your rough idea with moin developers (you can do that by private chat, so you don't disclose your idea publically), you might get quick feedback before writing a detailled proposal