This is a page for people to indicate what they'd like to see done in XWiki in priority. These lists are in no way official and do not represent the Roadmap.

These list can be used for example to prepare team brainstormings or they simply provide visibility about what people find important to do, thus increasing the awareness of the topics.

• List: Vincent
• List: Thomas
• List: Marius
• List: Caty
• List: Eduard
• List: <other>

List: Vincent

3 General Themes for 8.x:

1. Increase adoption rates of XWiki. Consequences:
   • Improve confidence in Extensions (people go away when they try XWiki and find extensions that don't work)
   • Flavors
   • Importers (to move from another wiki to XWiki)
   • External integrations to make XWiki not an island and make it join existing ecosystems (sharepoint, google docs/apps)
2. Increase active users (goal: reach 10000 active installs in 5 years. We're at 2000). Consequences:
   • Usability items, polishing
   • Performance
3. Increase XWiki's attraction as a platform working on dev tools. Consequences:
   • Integrated Web IDE (Improved AWM)
   • JS fwk to be able to create apps fully in JS. Side note: this also helps in recruiting because it's easier/more exciting for web devs to be working on JS than to be working on Velocity.

Sorted from most important to less important:

• General: Polish, polish, polish! For each feature, work on it till it's the best in the world from the point of usability.
• Usability: Improve user confidence in XWiki Extensions:
  • Ability for users to report more easily and from their wiki when an extension doesn't work with their version
  • Ability for the EM to verify if an extension works with the user's xwiki version when installing it and warning if it doesn't
  • Sort Extensions by rating in the Repository app's home page
  • Add ability to enter an XWiki version on the Repository home page and get the list of extensions that have been explicitly reported to work for that version
• Performance: Fix Activity Stream's performance
• Performance: Improve page loading time
• Define a JS fwk to be able write XWiki apps fully in JS (MVC in JS)
• Usability: Improve Rights UI
• Usability: In the wiki editor, when entering a link in wiki syntax, provide a suggest for finding the reference to a page. Right now it's a pain to have to remember the name of a page when you're creating links.
• Usability: In the wiki editor, when entering a link in wiki syntax, have the ability to paste a full URL as the reference and have XWiki convert it to a reference automatically, either on the fly before saving the page (ideally the best) and/or when saving the page.
• Usability: Page aliases (for renames/deleted + for short urls): http://design.xwiki.org/xwiki/bin/view/Proposal/DocumentAliases and http://markmail.org/message/d34smnyap5y6l24c
• Dev: production-quality-level Application Development Environment: Web IDE merged with AWM + Syntax Highlighting + Auto Completion
• Feature: Finish Flavors and Transform XE into a real Flavor.
• Feature: Mediawiki importer filter (same as the confluence one)
• Feature: Integration with Google Docs (bidirectional integration):
  • Add Page > From Google Docs
  • When on an imported page, have a Refresh button to update the page, using our 3-way merge
  • When on a page add an Export > To Google docs
• Feature: Integration with SharePoint. To be defined precisely.

List: Thomas

• really start the minimalistic XWiki distribution and flavors (make it the 8.x theme)
• move xwiki/1.0 extension (xwiki-platform-oldrendering) to contrib
• upgrade hibernate
• upgrade restlet
• more performances work
  • new set of script oriented API and reusable UI component for asynchonous tasks
  • async everywhere (page rendering, panels, macros, etc.)
  • memory and performances improvement on delete and history handling
  • miscelaneous
• Extension Manager
  • release extension from the wiki
  • more extension related actions (reinstall, clean local extension, download, etc.) and make extension actions in the UI extensible (they are fully hardcoded right now) so that any extension type handler (or any other extension) can add more stuff
  • grades and comments from Extension Manager (right now it only display grades)
• more stuff in the Distribution Wizard
  • various checks (memory, permanent dir, etc)
  • get rid of admin user and as the user to register before installing anything
  • other stuff
• move to Java 8
• fully scalable import UI
  • allow putting any InputSource for the XAR file (URL, file or folder on FS, etc.)
  • allow directly importing a XAR while uploading it (i.e. not go trough attachment and pages selections)
  • don't parse the XAR to find document to select by default, only if the user expand it
• lots of new xclass properties (IP, color, etc.) and make easier for an extension to add its own
• better image resize framework (seems to be just about using the lib indicated in https://jira.xwiki.org/browse/XWIKI-7623)

List: Marius

• CKEditor integration
• Wiki Editor improvements
  • share the same wizards as the WYSIWYG editor (for link, image, table, macro insertion/editing)
  • line numbers, syntax highlighting, auto-complete, full screen
• Solr Search improvements for big wikis (e.g. xwiki.org, myxwiki.org)
  • investigate and improve the relevancy of Solr search results on big wikis (e.g. by tweaking the boost factors)
  • spell checking / suggestion for search terms
  • UI scalability (especially for search facets)
• Investigate alternatives to JodConverter for Office Import or integrate patches from others forks
• Continue the work on improving the upgrade process
• Enable refactoring from the tree view (rename, drag & drop copy/move, delete)
• Batch operations on live tables (using a selection column)
• Improve the Diagram Application by integrating a better (Open Source) library than draw.io

List: Caty

• Improved xwiki.org (7.4.x+, re-organized documentation, download, etc.)
• Versioned Documentation on xwiki.org (versioned objects that can be added to doc pages, that contain version changes. On the Release Notes just aggregate the info found in these objects. This way we don't document in RN, but on e.x.o and RN are auto-generated. Problems with performance?)
• Improving e.x.o (issue tracker for major extensions encouraging participation, ratings displayed, archive old extensions)
• Tour Application for first time users. This functionality could also be expanded so that each Application can provide a Tour describing it's functionality. Apps should define a dependency on Tour and provide a Tour instance for basic functionality, or even for each new version.
• Help Center (local Documentation, Getting Started, Syntax, FAQ, or links to external doc)
• Clean-up Platform (Stats, Invitation, Annotations, etc.) to the appropriate repo
• Unbundle old apps and keep only relevant/polished/flavor dedicated apps
• Provide Flavors for Platform. Each flavor would match a known use case. Community Flavors could be voted and integrated.
• Rights Roles (administrator, developers, users, etc.) the simplest implementation would be to provide these groups by default with appropriate rights set
• Notifications
• Skin Editor (visual organization of UIXPs)
• Workflow integration for DocFlavor
• Applications providing own Templates (Event, Post, etc.) = make this a standard for GroupwareFlavor
• Allow AWM apps to select different views (livetable, calendar, activity, cards)
• Keep #docextra only for content pages (Page Administration)
• Github, Google, Facebook log-in
• Sass, PostCSS extensions possible

List: Eduard

• Cleanup:
  • Drop @deprecated stuff that bloat the code (like 2.x deprecated stuff still in the product)
  • Drop inline edit mode (also deprecated)
  • Drop tiny_mce?
    • Still needed for 1.0 syntax wysiwyg?
• High-profile Usability improvements:
  • Integrate Syntax Highlighting & Autocomplete in XE by default
  • Lock-free editing
  • When leaving the edit mode without saving, notify the user that there are changes he needs to save ( XWIKI-6927 )
  • Review the CAPTCHA investivation and implement Google's RECAPTCHA since the public website flavor suffers from SPAM issues, AFAIK
  • Continue work on Real Time watchlist and end up enabling it by default.
• Bugfixes
  • Required javascript modules fail to load on a clear cache (or new document) ( XWIKI-12860)

List: <other>