diff --git a/TagsInMelange.md b/TagsInMelange.md
new file mode 100644
index 0000000..c2a674a
--- /dev/null
+++ b/TagsInMelange.md
@@ -0,0 +1,112 @@
+# Drivers
+
+Seven drivers for Tags in Melange are:
+
+  * Tags in GHOP
+  * Tags for GSoC organizations, like the ones here **http://delicious.com/gsoc2009**
+  * For large orgs: Tags for GSoC **project proposals**, so that mentors can say which projects are for which sub projects.
+  * Tags for mentors/students (for **umbrella orgs** to group those by 'subgroup')
+  * Tags are important to **statistics**, for example looking at stats for C++ projects and comparing to stats for Lisp projects.  Tags are likely to give some of the most interesting stats.
+  * Tags could be the basis for implementation of flexible **notifications**.  For example, notify me about all FSF projects tagged '3D'.  Or I could create a custom tag and apply it to the items for which I wanted notification.
+  * Tags could be the basis for **'bulk accept'**.  Wherever we have a list with checkboxes we could implement that with a tag.  This is like gmail's implementation of the inbox, the starred mail items and the selected mail items.  These are probably implemented with tags 'inbox', 'is-starred', 'is-selected' respectively.
+
+These **[requests for tags](http://code.google.com/p/soc/issues/list?can=1&q=%22425%22&sort=id&colspec=ID+Summary)** are worth looking at.
+
+# Requirements
+
+  * List views should support filtering on tags
+
+# Priorities
+
+  1. tagging of GHoP tasks
+  1. tagging of organisations
+  1. tagging of other entities
+
+# Tags vs Drop-Downs (implementation)
+
+  * Some tags are **mutually exclusive**.  _We will not be supporting this in our first implementation._
+  * Other **tags can be multiple**.  For example a project like Blender uses C++ and Python.  A GHOP task may be both Documentation and Translation (TBC).
+
+# Tags in GHOP
+
+Tasks have types and they also have states.  States will be implemented as a drop-down, i.e. not using the tags implementation.  Types will be implemented as tags.  It is not sufficient to allow one tag per task. We should also allow arbitrary tags like language (e.g. Perl), difficulty (e.g. easy), mentor= (e.g. mentor=LH). The types (and states) listed below are completely accurate for GHOP.
+
+  * Each task needs to fall under at least one of the task-type categories. There will be a way to setup additional tags but the listed task-type tags will be the main one.  We can have two types of tags:
+    * **User tags** where users can set whatever tags they want
+    * **System tags** which users are forced to use by contest rules.
+
+## GHOP Task Types
+
+  * Each GHOP task should be tagged (Documentation, User Interface, Code, etc), GHOP admin/host can setup available tags in GHOP Melange configuration page, that way later on there are no typos and Melange can easily generate statistics for particular types of tasks. Tasks will typically fall into the following categories:
+    * **Code:** Tasks related to writing or refactoring code,
+    * **Documentation:** Tasks related to creating/editing documents,
+    * **Outreach:** Tasks related to community management and outreach/marketing,
+    * **Quality Assurance:** Tasks related to testing and ensuring code is of high quality,
+    * **Research:** Tasks related to studying a problem and recommending solutions,
+    * **Training:** Tasks related to helping others learn more,
+    * **Translation:** Tasks related to localization,
+    * **User Interface:** Tasks related to user experience research or user interface design and interaction
+
+In addition to these, Mentors/Org Admins can add arbitrary tags for the task type.
+
+## GHOP Task Statuses
+
+_Included here, but these will be implemented as a normal status field, not as tags._
+
+  * Each task should have one of the following **task statuses**:
+    * **Open:** This task has not yet been claimed,
+    * **Reopened:** This task has been claimed but never finished and has been reopened,
+    * **Claimed:** This task has been claimed and someone is working on it,
+    * **ActionNeeded:** Work on this task must be submitted for review within 24 hours,
+    * **Closed:** Work on this task has been successfully completed.
+  * additional states need polishing/**review with legal**
+    * **NeedsWork:** This task is nearly there, but a bit more must be accomplished. (following mentor review)
+    * **NeedsReview:** Student has submitted work for this task and it should be reviewed.
+
+
+# Tag Discussions (GSoC mostly)
+
+Tags were one of the most popular feature requests in prior years - and this year too.
+
+  * Large umbrella orgs running multiple projects would like to be able to view student proposals **by project**, since proposal titles are all over the place (vary significantly and sometimes don't name the project at all). Students could link proposals to a project using a list provided by the org admin, OR this could be accomplished through tags.
+  * Tags could also be the **basis of notifications**.  I could choose to follow all proposals tagged 'Tor'.  This possibility is also mentioned on [UserPreferencesPage](UserPreferencesPage.md).
+  * **Private Tags** - possibility to add tags that are seen only by one organization, or seen only by one user.
+
+For tagging to work for linking student proposals to a project, we'd need two additional features:
+
+  1. **Students can add tags** -- give each project a tag name on our organization's project page and insist that student tag their proposal using the tag name for their project. This way mentors/admins aren't forced to do all of the tagging later.
+    * We need some more thought on this, e.g. in our initial implementation we might restrict creation and selection of tags to mentors.  We don't/won't have an easy 'undo' in our first GHOP implementation.
+  1. **Tags can be removed or renamed** (at least by mentors) -- since student project assignments can change during the review process, we'd need a way to replace a "FooProject" tag with a "BarProject" tag
+
+Oh, and public categories should be almost completely inflexible, or it will quickly degrade into one category per organization, at a net loss of usability.  It should be possible to suggest new categories, but the final decision should be made by the "Category Czar".
+
+
+  * **Gmail has lovely tags**. Particularly nice is the ability to select multiple items and with a single change add or remove the same tag.
+  * Sometimes tags need to be 'managed', where a **"Category Czar"** can define what the tags are, but a wider pool of people can add or remove them.
+  * Are **hierarchical tags** useful? In the organisations page we have two tag families, the Language. tags and the Category. tags.
+  * Perhaps something like the issue tracker's **two-tiered tags**? Type-Feature, Priority-Low, etc?
+
+# Resources
+  * Datatables [can filter out of multiple columns](http://www.datatables.net/examples/example_multi_filter.html)
+  * [GAE Open source projects with tags support](http://groups.google.com/group/melange-soc-dev/browse_thread/thread/54b6839bcbdf0493)
+  * [Comparison of taggable-mixin and gaegene tags support](http://groups.google.com/group/melange-soc-dev/browse_thread/thread/500be96e494c6248)
+
+_For our needs, taggable.py (the mixin) was a clear winner in the comparison of tags implementations_
+
+# Questions
+
+  * **Q:** Will survey results be taggable?  Will documents be taggable?  This question is really asking if there are expected to be technical difficulties in extending taggable.py to these 'non-standard' models.  For example, is taggable compatible with expando?  Are we putting taggable in the right place in our hierarchy to catch documents too?
+  * **A:** When it comes to Documents we can make them taggable, but survey I'm not sure if we need that kind of functionality. We can always add it later if it turns up we need it. We will extend Taggable to support different kinds of tags. No, there is no need to have taggable compatible with expando model.
+
+  * **Q:** With standard tagable.py, finding out what tags an entity has been tagged with requires a query for each entity.  That's expensive when showing tags for rows in a table.  When we add a tag to an entity, we could choose to add it to the tags _and_ add it to a string property in the entity.  Will we be doing this?
+  * **A:** When it comes to that we will extend Taggable to support that functionality.
+
+
+# Testing
+
+To complement the use of taggable.py, seed\_db.py will need to put some tags down as well as seeding other tables.  One suggestion is that seed\_db.py should:
+
+  * Tag organizations (as C++, Python, Ajax, Assembler)
+  * Tag student project proposals (as Easy, Moderate, Hard; 3D, LAMP, Audio, Embedded)
+
+This will help and promote use of tags in stats.  It will enable the development of python code in the stats module to collect the tag related information.
\ No newline at end of file
diff --git a/TagsInMelange.wiki b/TagsInMelange.wiki
deleted file mode 100644
index a0b2cd3..0000000
--- a/TagsInMelange.wiki
+++ /dev/null
@@ -1,115 +0,0 @@
-#summary Design/discussion of Tags
-#labels Importance-Details,Phase-Design,Contents-Draft
-
-= Drivers =
-
-Seven drivers for Tags in Melange are:
-
-  * Tags in GHOP
-  * Tags for GSoC organizations, like the ones here *[http://delicious.com/gsoc2009]*
-  * For large orgs: Tags for GSoC *project proposals*, so that mentors can say which projects are for which sub projects.
-  * Tags for mentors/students (for *umbrella orgs* to group those by 'subgroup')
-  * Tags are important to *statistics*, for example looking at stats for C++ projects and comparing to stats for Lisp projects.  Tags are likely to give some of the most interesting stats.
-  * Tags could be the basis for implementation of flexible *notifications*.  For example, notify me about all FSF projects tagged '3D'.  Or I could create a custom tag and apply it to the items for which I wanted notification.
-  * Tags could be the basis for *'bulk accept'*.  Wherever we have a list with checkboxes we could implement that with a tag.  This is like gmail's implementation of the inbox, the starred mail items and the selected mail items.  These are probably implemented with tags 'inbox', 'is-starred', 'is-selected' respectively.  
-
-These *[http://code.google.com/p/soc/issues/list?can=1&q=%22425%22&sort=id&colspec=ID+Summary requests for tags]* are worth looking at.
-
-= Requirements =
-
-  * List views should support filtering on tags
-
-= Priorities =
-
-  # tagging of GHoP tasks
-  # tagging of organisations
-  # tagging of other entities
-
-= Tags vs Drop-Downs (implementation) =
-
-  * Some tags are *mutually exclusive*.  _We will not be supporting this in our first implementation._
-  * Other *tags can be multiple*.  For example a project like Blender uses C++ and Python.  A GHOP task may be both Documentation and Translation (TBC).
-
-= Tags in GHOP = 
-
-Tasks have types and they also have states.  States will be implemented as a drop-down, i.e. not using the tags implementation.  Types will be implemented as tags.  It is not sufficient to allow one tag per task. We should also allow arbitrary tags like language (e.g. Perl), difficulty (e.g. easy), mentor= (e.g. mentor=LH). The types (and states) listed below are completely accurate for GHOP.
-
-  * Each task needs to fall under at least one of the task-type categories. There will be a way to setup additional tags but the listed task-type tags will be the main one.  We can have two types of tags: 
-    * *User tags* where users can set whatever tags they want
-    * *System tags* which users are forced to use by contest rules.
-
-== GHOP Task Types ==
-
-  * Each GHOP task should be tagged (Documentation, User Interface, Code, etc), GHOP admin/host can setup available tags in GHOP Melange configuration page, that way later on there are no typos and Melange can easily generate statistics for particular types of tasks. Tasks will typically fall into the following categories: 
-    * *Code:* Tasks related to writing or refactoring code, 
-    * *Documentation:* Tasks related to creating/editing documents, 
-    * *Outreach:* Tasks related to community management and outreach/marketing, 
-    * *Quality Assurance:* Tasks related to testing and ensuring code is of high quality,
-    * *Research:* Tasks related to studying a problem and recommending solutions, 
-    * *Training:* Tasks related to helping others learn more, 
-    * *Translation:* Tasks related to localization, 
-    * *User Interface:* Tasks related to user experience research or user interface design and interaction
-
-In addition to these, Mentors/Org Admins can add arbitrary tags for the task type.
-
-== GHOP Task Statuses ==
-
-_Included here, but these will be implemented as a normal status field, not as tags._
-
-  * Each task should have one of the following *task statuses*: 
-    * *Open:* This task has not yet been claimed, 
-    * *Reopened:* This task has been claimed but never finished and has been reopened,    
-    * *Claimed:* This task has been claimed and someone is working on it, 
-    * *!ActionNeeded:* Work on this task must be submitted for review within 24 hours,
-    * *Closed:* Work on this task has been successfully completed.
-  * additional states need polishing/*review with legal*
-    * *!NeedsWork:* This task is nearly there, but a bit more must be accomplished. (following mentor review)
-    * *!NeedsReview:* Student has submitted work for this task and it should be reviewed.
-
-
-= Tag Discussions (GSoC mostly) =
-
-Tags were one of the most popular feature requests in prior years - and this year too.
-
-  * Large umbrella orgs running multiple projects would like to be able to view student proposals *by project*, since proposal titles are all over the place (vary significantly and sometimes don't name the project at all). Students could link proposals to a project using a list provided by the org admin, OR this could be accomplished through tags.
-  * Tags could also be the *basis of notifications*.  I could choose to follow all proposals tagged 'Tor'.  This possibility is also mentioned on [UserPreferencesPage].
-  * *Private Tags* - possibility to add tags that are seen only by one organization, or seen only by one user.
-
-For tagging to work for linking student proposals to a project, we'd need two additional features:
-
-  # *Students can add tags* -- give each project a tag name on our organization's project page and insist that student tag their proposal using the tag name for their project. This way mentors/admins aren't forced to do all of the tagging later.
-     * We need some more thought on this, e.g. in our initial implementation we might restrict creation and selection of tags to mentors.  We don't/won't have an easy 'undo' in our first GHOP implementation.
-  # *Tags can be removed or renamed* (at least by mentors) -- since student project assignments can change during the review process, we'd need a way to replace a "!FooProject" tag with a "!BarProject" tag
-
-Oh, and public categories should be almost completely inflexible, or it will quickly degrade into one category per organization, at a net loss of usability.  It should be possible to suggest new categories, but the final decision should be made by the "Category Czar".
-
-
-  * *Gmail has lovely tags*. Particularly nice is the ability to select multiple items and with a single change add or remove the same tag.
-  * Sometimes tags need to be 'managed', where a *"Category Czar"* can define what the tags are, but a wider pool of people can add or remove them.
-  * Are *hierarchical tags* useful? In the organisations page we have two tag families, the Language. tags and the Category. tags.
-  * Perhaps something like the issue tracker's *two-tiered tags*? Type-Feature, Priority-Low, etc? 
-
-= Resources =
-  * Datatables [http://www.datatables.net/examples/example_multi_filter.html can filter out of multiple columns]
-  * [http://groups.google.com/group/melange-soc-dev/browse_thread/thread/54b6839bcbdf0493 GAE Open source projects with tags support]
-  * [http://groups.google.com/group/melange-soc-dev/browse_thread/thread/500be96e494c6248 Comparison of taggable-mixin and gaegene tags support]
-
-_For our needs, taggable.py (the mixin) was a clear winner in the comparison of tags implementations_
-
-= Questions =
-
-  * *Q:* Will survey results be taggable?  Will documents be taggable?  This question is really asking if there are expected to be technical difficulties in extending taggable.py to these 'non-standard' models.  For example, is taggable compatible with expando?  Are we putting taggable in the right place in our hierarchy to catch documents too?
-  * *A:* When it comes to Documents we can make them taggable, but survey I'm not sure if we need that kind of functionality. We can always add it later if it turns up we need it. We will extend Taggable to support different kinds of tags. No, there is no need to have taggable compatible with expando model.
-
-  * *Q:* With standard tagable.py, finding out what tags an entity has been tagged with requires a query for each entity.  That's expensive when showing tags for rows in a table.  When we add a tag to an entity, we could choose to add it to the tags _and_ add it to a string property in the entity.  Will we be doing this?
-  * *A:* When it comes to that we will extend Taggable to support that functionality.
-
-
-= Testing =
-
-To complement the use of taggable.py, seed_db.py will need to put some tags down as well as seeding other tables.  One suggestion is that seed_db.py should:
-
-  * Tag organizations (as C++, Python, Ajax, Assembler)
-  * Tag student project proposals (as Easy, Moderate, Hard; 3D, LAMP, Audio, Embedded)
-
-This will help and promote use of tags in stats.  It will enable the development of python code in the stats module to collect the tag related information. 
\ No newline at end of file