Semantic MediaWiki/Archive

Keep some history from old projects

For software features

See Features-test page for some sample work. On December 9th S Page split Feature roadmap into 76 separate subpages (!!!), and it went live December 12th..

Original proposal

Greg in October e-mail said

I want to come up with a set of feature, then slice them by a couple of different "selects".

That is:

• list all features by requestor (e.g. Peru or Scott)
• list them by technology
• list them by strategic relevance (e.g. stability)
• probably some others (e.g. developer, contacts etc.)

I also want to have 2 - 3 levels of detail on each. The main page can list the characteristics per above. Then each feature can link to a detailed requirements definition and a specification (or design proposal).

User:Skierpage comments

As we can see with Release notes and Future releases, wiki users get frustrated with the summaries generated by queries, so they write and maintain their own summaries alongside query results. So unless people are willing to have a "9.1.0 features" summary that they can't edit, annotating all this data will add more information and work!

• A details page for each feature, in Category:Software features
• Each feature page has 0-to-many Property:Requested by saying who requests it.
  • This could be a many-valued property -- "requested by OLPC Peru, with priority High", though they're a little clunky to edit.
  • A deployment or user can still easily "list all pages requested by me", just query [[Requested by::{{FULLPAGENAME}}]]).
  • Note the inverse, adding 0-to-many Property:Requests featureto each deployment page, makes it very difficult to have a summary table showing a feature, its technology, and who requests it (you can't really do a join between "list of feature pages" and "pages requesting features").
• Each feature page can have various technology categories (see CScott's Category:Subsystems?). A simple query will show all its categories.
• I'm not sure what property or category to use for strategic relevance...
• 2-3 levels of details sounds like Activities' use of Property:Short description and Property:Description. Note multiple "description" properties frustrate editors and get misused or stale, especially if they're in a form that makes people repeat what they already said in opening paragraphs.

Looking at Feature roadmap, a country request like "Collaboration in groups" decomposes into one or more requirements. Does a country request map to a feature, or is each requirement a separate feature, or is a feature composed of requirements from various requestors? People might not like their specific request map to a feature — "That's not what I asked for, it's just something related you decided to do!" It's possible to model grouping and subsetting in SMW, but it means more pages to edit and more complicated queries.

Later Greg wrote

• Then I plan to start tagging items for 9.1 and adding other tags. For 9.1, a quick filter will show what is top priority for that release. In the end I want it to look like this: https://launchpad.net/ubuntu/+specs

User:Skierpage comments:

You can implement properties corresponding to all the fields in that "Ubuntu Blueprints" link (Has_design_status, Has_delivery_status, Is_assigned_to, For_build_stream). It might be simpler to just have a Property:Feature_has_status on each feature page with allowed values like "high priority for 9.1.0", "9.1.0 candidate", "may defer post-9.1.0", etc.

Software features December proposal

December 2 Greg wrote to wiki-gang@laptop.org (skierpage comments indented)

How about we start by taking sections 6.2 - 6.8 and adding Semantic tags to that.

Each feature should like to its own page. All the fields for a feature will be visible on its detail page.

The main feature roadmap page will only show a query. That query will show:

• Name

Greg wants the page titles prefixed "Feature roadmap/name of feature".

• Primary requester (this field does not exist right now. We should be forced to pick one, then the rest can be in a new field called other requesters, or all requesters and it will show on the detail page. We can start by just changing the existing field and leaving "primary" blank until its filled in).

Created Property:Primary_requester, then agreed to remove it.

also Property:Requested by for Requesters , that you can use more than once.

• Category (this will be the .n level feature section, e.g. "activity-related work" etc.)

OK, subcategories of Category:Software features. For display and sorting, also shows up as Is part of::Category:whatever. There's also User:Mstone's idea of Category:Subsystems

• Helps deployability Y/N (new field, binary)

Done, Property:Helps deployability

• Target for 9.1 Y/N (new field, binary)

Done, Property:Target for 9.1. BUT doesn't parse, maybe "Is planned for 9.1" is better? Also is inflexible, could instead do Feature_status::"Target for 9.1"/Defer/etc., or Targeted_for_release::"9.1.0"/9.1.1/9.2.0/Future/ that are more flexible.

• Assign OLPC resources Y/N (new field, binary)

Doesn't parse, is this phrase a command, a TODO, or ??? Would it be more flexible to have Property:Team member::User:CScott , etc.?

• Owners (same as it is today)

Instead let's Property:Contact person that you can use more than once.

• Priority (Critical, High, Medium, Low)

Done, Property:Priority, with numbers in front so they sort right and you can query for priority < 2. ISSUES: Should these match trac's blocker, high, normal, low?

Start with a query sorted by Category.

Details

Subcategories of Category:Software features, or use Property:Is part of some Category:Subsystems? The latter is User:Mstone's attempt to organize Subsystems, unfortunately it doesn't quite map to the subsections of the feature roadmap.

The subcategories of Category:Software features (including alas sub-sub-categories) are (dynamic query)

{{#ask: Category:+

 | format=list
 | link=all

}}

The static subcategories of Feature roadmap#Roadmap were (static list as of 2008-12-02)

Activity-related work, Collaboration, File Manipulation, GUI, Usability, Journal, Hardware support, Localization, Network, Other, Performance, Power management, Reliability, , Security, activation and deployability, Server

The subsystems in Category:Subsystems are (dynamic query)

{{#ask:

 | format=list
 | link=all
 }}

Page splitting tech details

1. Edit Feature roadmap#Roadmap
   • Clean up {{Feature request}} names to follow OLPC:Style guide
   • Clean up subsections so they can be good category names — no slashes, no punctuation
2. Open vim, :set encoding=utf-8
3. Copy wiki markup to vi
4. Fix Name= to be lower-case feature names.
5. Add some formatting to it using perl -n fixname.pl, or the vim commands are roughly:
   • :%s/{{Feature_request/{{-stop-}}^V^M{{-start-}}&/ add start and end markers
   • :%s/{{Feature_request/{{XFeature_request/ different template
   • :%s:|Name=\s*:Name=Feature roadmap/: put page into sub-area
   • Also need the page subsection to be a property since subcategories don't work well, so add |feature_subcategory=Activity-related work to XFeature template
6. Clean up the resulting script: remove extra whitespace and some stray text after clipboard feature.
7. Configure Pywikipedia bot using lfaraone's config file e-mailed to wiki-gang.
8. Use Pywikipedia bot's Pagefromfile command to load pages

 path/to/python login.py
 path/to/python pagefromfile_x.py -debug -file:feature_pages.txt -include  -titlestart:"Name=" -titleend:"\n"

or if using perl,

 ''path/to/python pagefromfile_x.py -debug -file:feature_pages.txt -notitle

1. Remove -debug and run again if it looks good.