History of TWiki Roadmap

This topic is an old roadmap discussion which have been moved from TWikiRoadMap.

See TWikiRoadMap for an up to date roadmap as of August 2007

---

Context

See TWikiReleases for past and future planned releases

Overview

The purpose of this topic is to discuss the creation of a "road map" for development of the TWiki platform.

We believe that such a roadmap will be very helpful for TWikiAdvocacy and outreach to prospective users and, perhaps even more importantly, prospective development partners.

For the sake of this discussion, we are using the following working definition:

TWikiRoadMap is a strategy and planning document for TWiki. It lists the current priorities for improvement and feature development. The intention is to provide a well-articulated step-by-step plan that, if well executed, will help fulfill TWiki�s mission to gain wide adoption of TWiki. The TWikiRoadMap will include a list of top priority development objectives that are most likely to energize our user and developer community.

For feedback and discussion on this working definition, go here.

Status as of 11/17/04

A significant(?) number of active TWiki community members have expressed support for creating a TWikiRoadMap. We've extended the deadline to add your vote!

The current focus of discussion is brainstorming TWikiRoadMap priorities.

Background: CrawfordCurrie initiated the discussion on 01Oct04 and LynnwoodBrown proposed to use this discussion as a experiment in WikiFacilitation in early November. Earlier aspirations towards "fast-tracking" this discussion for completion by December 15th have been dropped, however the intent is still to maintain some time constraints for each step, so please don't wait to give your imput.

Some tentative milestones towards achieving this goal are:

• November 10 - Finalize working definition of "road map."
• December 10 - Complete brainstorming of list of possible objectives to include in TWikiRoadMap
• December 15 - Refine the brainstorm list to include in poll for support.
• December 24 - Close poll for top priority objectives to include in TWikiRoadMap.
• December 31 - 1st draft of TWikiRoadMap presented (A little New Year's gift to the TWikiCommunity )
• Mid January - Finalize draft of TWikiRoadMap

(For comments and discussion on it go here).

---

Structured Input

This section is for allowing quick input on specific aspects of the discussion around creating a TWikiRoadMap.

Poll: Is creating a TWikiRoadMap important?

Do you agree that having a TWikiRoadMap is an important thing for TWikiAdvocacy and outreach?

Do you agree or disagree? Please select one of the radio buttons below and click the button. I 1 - Strongly disagree   2 - Disagree   3 - am Neutral   4 - Agree   5 - Strongly Agree

3	BrunoRino	19 Jan 2006
4	EricCote	12 Feb 2005	road maps help to focus a person/project/group; helps in minimising people/resource wastage. we're all very busy, and anything that helps to focus is good.
4	IanAllinson	23 Jan 2005	As a potential user who thinks Twiki looks very promising, but recognises that it doesn't (yet) do all I need, it would be helpful to understand which directions it will develop in.
5	SamHasler	09 Dec 2004
1	KeithHelfrich	01 Dec 2004	as a TWikiSite administrator, I believe the roadmap would be very useful for me. And it would also help with TWikiAdvocacy.
5	SvenDowideit	17 Nov 2004	I agree, its very true that a RoadMap is important, both to focus people's efforts, and to show others what buy-in there is for ideas and directions. I have previously suggested that each person should have a PersonalRoadMap which would allow all of us to co-ordinate our interests, and then from that we could distill that into a joint RoadMap. That said, I'd be interested to see what you come up from what you see around here.
5	RafaelAlvarez	05 Nov 2004	A roadmap is important so new users and developers know where we are heading, and also give a point of reference to the TWikiMission.
4	FranzJosefSilli	05 Nov 2004	Would mindmapping help the process?
5	CrawfordCurrie	05 Nov 2004	If I didn't agree, I wouldn't have tried drafting one myself. "Where's the roadmap" is possibly the second most common comment I hear from people who I introduce from TWiki.org.
5	MattWilkie	05 Nov 2004	A roadmap is important, but only if it actually speaks to the needs and desires of the community. If it's imposed or orthagonal it will be ignored. And if it's too vague and general it can't be followed.
5	LynnwoodBrown	05 Nov 2004
5	WillNorris	05 Nov 2004
5	MartinCleaver	05 Nov 2004	I hope everyone will join us to engage in this process.

For me, the real starting place for this discussion is to check in if their is sufficient community support for creating a TWikiRoadMap. I'm not going to waste yours or my time if this is something that only a small handfull of people care about. Without community support, a TWikiRoadMap has no meaning.

I'm looking at this as more than just a poll. I would encourage folks to think in terms of a positive response also indicating your commitment to participate in this discussion and see it through to completion. I'm not talking heavy lifting here - simply checking in regularly, responding to polls as they evolve, and adding comments as you can.

-- LynnwoodBrown - 04 Nov 2004

KeithHelfrich, did you really mean to vote 1? The vote don't go with your comment

-- RafaelAlvarez - 01 Dec 2004

I've removed the deadline on people showing their support for this discussion. In retrospect, this seems kind of pointless. Why deny folks the option of showing support just because they joined in later? So, if you think a TWikiRoadMap would be a good thing, by all means add your vote. Actually, it would also be great to hear from folks who don't see the value of having a TWikiRoadMap!

-- LynnwoodBrown - 08 Dec 2004

Brainstorming: Possible things to include in TWikiRoadMap

This section is for initial brainstorming of improvements and enhancements to include in a TWikiRoadMap. The brainstorming phase will continue until November 22. After that, we will focus on prioritizing and refining the list. (I'll figure out how when we get to that phase).

Table Summarizing Brainstorming

The following table summarizes ideas developed in brainstorming priorities for TWikiRoadMap. Feel free to add to or modify the table if you feel your idea was left out or mis-represented. I know I left some out that I did not understand. If you do modify the table, please try to be rigorous with your language as I've attempted to be in line with my notes on format. If you simply want to throw out a new idea, add it here -- LB - 17 Nov 2004

Discussion of brainstorming

-- LynnwoodBrown - 04 Nov 2004

I'd like to emphasize "user-experience". For example, a login/out page rather than the default popup dialog box which is very intrusive and scares people off. Also the requiring people to log in in order to use the Jump box (aka GoBox) is just silly.

-- MattWilkie - 05 Nov 2004

Prune the docs! Ironically a major problem with twiki is there is too much documentation. The trees are lost for the forest. Admittedly, this is hard, but it needs to be done.

-- MattWilkie - 05 Nov 2004

Enhance the API for creating Plugins and AddOns, and make it easier to create new skins

-- RafaelAlvarez - 05 Nov 2004

Selling to techies - performance counts

Selling to end users and managers, its more than the "user experience", its the application. They only see the "user experience" in terms of the application. While the contributions made by people such as ArthurClemens are wonderful, they are only in terms of what I would term the 'content managers' view of things, not the "real end-user". We still need a "Portal" style interface.

-- AntonAylward - 05 Nov 2004

I've bolded the key phrases in people's comments above in anticipation of refactoring the brainstorm list in the next couple of days. I'm also looking for some evocative phrases to refer to the different areas of development and improvements. From what I've heard so far, I'm thinking maybe Performance Improvements, Enhanced User Experience, Improved Data Structures, and maybe *Plug & Play Applications (for applications & cookbooks).

-- LynnwoodBrown - 10 Nov 2004

Note on formating in summary table

In drafting the brainstorming summary table, I thought it would be useful to begin to standardized and simplified our language. My thinking here is that we eventually want a TWikiRoadMap statement is (1) grammatical (i.e. has parallel structure), (2) succinct , and (3) understandable to the broadest possible audience. I also think stating our objectives in a similar format will help us in comparing and ranking them.

The format I propose has two basic parts:

1. An simple objective that expresses what we are going to do and the resulting solution.
2. The reason that presents the one or two top benefits that would result.

In addition, I have made a first cut at grouping these into development areas. Again, I've tried to come up with names that are descriptive and readily understandable. Did I succeed? Have I left out any? If you don't see how your idea fits into one of the groups, select "Other" and suggest another name.

-- LynnwoodBrown - 17 Nov 2004

---

Topical discussion

This section of the topic is devoted to specific aspects of TWikiRoadMap development.

Time Frame for Creating TWikiRoadMap

I am intentionally trying to push forward this discussion as quickly as possible for two reasons. The first, of course, is that it would be really great to have a TWikiRoadMap sooner than later. I think it's already long overdue. The second is to try out WikiFacilitation. Specifically, there are a couple of things I want to test:

• Can we accelerate our collective deliberation and decision-making process without unduly compromising the quality of the result?
• Might imposing a timeframe actually make the discussion more engaging? In other words, will people be more motivated to give input when the discussion is not construed to continue ad infinitum?

Obviously, the particular time frame I'm proposing is arbitrary. What do you think? Is it OK?

-- LynnwoodBrown - 04 Nov 2004

I'd be suprised if you get adequate input in that timeframe, unless you specifically target key stakeholders.

-- CrawfordCurrie - 05 Nov 2004

What do we mean by TWikiRoadMap?

Before we can formulate a TWikiRoadMap, I feel that we need some general agreement on what we mean by this phrase so we don't end up talking apples and oranges. I have posted a draft in the "Overview" of what I understand it to mean. In addition, here are a couple of thoughts about what I think would make a good TWikiRoadMap:

• Make it short so people will read it.
• Avoid TWiki jargon so the uninitiated will understand what we're talking about (and maybe become initiated.
• Make it focused on the most important things we want to accomplish - not a long wish list.
• Focus on compelling by focusing on enhancements that will attract the broadest audience.

Am I on track here? Please give feedback on the draft definition and these additional thoughts. Remember that I want to finish up the discussion on definition by November 12, so please focus on that first.

-- LynnwoodBrown - 04 Nov 2004

I'm wondering if the inclusion of a timeframe is really essential to a "roadmap." A map simply points to where we're going, not necessarily when we're going to get there. And trying to define the timeframe might be where this could really bog down. So I propose dropping reference to time frame.

-- LynnwoodBrown - 10 Nov 2004

Not hearing any objectives to my proposal above (assuming anyone was listening ), I dropped reference to time frame from definition of "road map." We can always add it back if someone speaks up.

-- LynnwoodBrown - 17 Nov 2004

Topic facilitation feedback & discussion

This section is for feedback and discussion for how the TWikiRoadMap topic is being facilitated. Since I am intending this to be an experiment in WikiFacilitation, your feedback and general impressions would be very much appreciated! In particular, I'd like to hear what you think the topic organization. Does it make sense to you? Does it help make the discussion about TWikiRoadMap easier to understand and participate in? What improvements would you suggest?

-- LynnwoodBrown - 04 Nov 2004

In the brainstorming section, I'd like to create a Comment type that adds to a bullet list.

-- LynnwoodBrown - 05 Nov 2004

and not signed, who proposed the idea is irrelevant. It's either a good idea or it's not. They should stand on their own merit.

-- MattWilkie - 05 Nov 2004

I agree with you Matt. In the next couple days, I'm going to reformat the brainstorming section as a chart without names. I've created a generic form-comment template for this. My thinking is to have 3 columns listing "Improvement Area" (i.e. Performance, User Experience, Data Structure), Objective, and (optionally) related topics.

-- LynnwoodBrown - 10 Nov 2004

---

Open Discussion

This section is for commenting on anything and everything related to TWikiRoadMap and this topic. For now, it includes all the prior discussion up to now. Eventually, as the main points already raised are included into other sections of the topic, I may archive some of the discussion to help highlight more current discussions. -- LB - 04 Nov 2004

I know that some people don't like roadmaps, and past attempts to define one have been stillborn, but I personally am at a bit of a loss over what we are trying to do. So for the sake of my own sanity I thought I'd start this topic. I won't object (or be surprised) if it is silently deleted, but I hope not.

I have to say that I frequently come across the "what's the roadmap" question from people outside the project. I point them at the various DakarRelease, EdinburghRelease topics, but these are feature WIBNIFs and not a roadmap, and tend to confuse rather than clarifying.

The purpose of a roadmap is simply communication. It's a way of adding flesh to the mission and vision, a way of setting specific goals that lets people know what they should be working towards.

The TWikiMission sets the following high-level goals:

1. Enhance TWiki evolutionarily to fit the mission.
2. Easy maintenance is key.
3. KISS (keep it simple) design is preferred over complicated designs.
4. Design for a good "out of box experience"; advanced features are OK as long as they do not distract.
5. Keep CreepingFeaturitis to a minimum.
6. Low requirements on client side and server side as defined in RequiredEnvironmentForTWiki.
7. Keep the quality as high as it is, e.g. few or no bugs for production releases and deployable in many environments.
8. Give broad corporate appeal, without sacrificing above guidelines
9. Protect corporate investment (topic contents) from data corruption and incompatible changes - don't require the use of upgrade scripts (e.g. category to forms upgrade happened automatically)

Discussions about the mission are not appropriate here. I'm not interested in whether TWiki has stuck to this mission in the past. I'm only interested in how we address the mission in the future. Specifically, I'm interested in 8. IMHO TWiki is already good; I want it to be even better.

To kick off a discussion here's my prioritised list of things I think need doing to address 8, and re-energise the appeal of TWiki to coporate users:

1. fix performance issues
2. slicker marketing
3. make the first-time user experience much more pleasant
4. support corporate data-intensive twiki applications

I can see all these being done on a reasonable time horizon (within a year) so they are to my mind a reasonable basis for discussion. How can they be achieved? Just my opinion, but this how I see it (again, prioritised lists)

1. Performance
   1. Benchmarking process (see ExaminingPerformance)
   2. Documentation that correctly sets and manages user expectations
   3. Test framework to ensure equivalence between pre-change and post-change code
   4. Ensure honourable encapsulation of existing components - Store, Meta, Forms etc
   5. Gardening (dead features, refactoring) to simplify code & lighten the load, without compromising functionality in any way.
2. User experience
   1. Ensure supply of standard distribs i.e. rpm, apt
   2. WYSIWYG editor(s)
   3. Fix the locking model (ReleaseLocksOnSave)
   4. Simplify install process (maybe installer script?)
   5. Standardisation (e.g. a standard templating mechanism)
3. Data-intensive
   1. Alternative Store implementation 1, based on a DBD interface (separated meta and text)
   2. Topic Object model, and associated lookups http://twiki.org/cgi-bin/view/Codev/ContentAccessSyntax

General stuff that doesn't fit on the roadmap because it has to go on all the time:

• Slicker marketing
  • Finish the discussion about logos
  • Tidy up the face that TWiki presents to the world at large (refactor twiki.org?)
  • Encourage and develop evangelists,
  • Find & exploit press coverage opportunities.
  • More presentations at conferences.
  • Encourage corporate sponsors of TWiki based student projects.

Like I said, just my opinion. I'm exposed mainly to corporate users; I for one would love to hear input from:

• Personal users ("my wiki" types who use it as a CMS & personal notepad)
• Public site users (like the people who run sunsite; you know who you are!)
• People working on competititve/complementary technologies (other wikis, Mason, WebGUI)
• Anyone who disagrees!

-- CrawfordCurrie - 01 Oct 2004

i can tell you why i think TWikiRoadMap is not filled in, and suggested (and implemented) that each person that does stuff could help us by stating what their personal RoadMap is, and from there we should be able to see some trends.

-- SvenDowideit - 17 Oct 2004

There was a try to collect that information on DevelopmentAreaByPersonInterested.

-- RafaelAlvarez - 27 Oct 2004

In line with what I presented in WikiFacilitation, I propose that this is a good topic to test whether that model could help accelerate our process of reaching some kind of group agreement. Wouldn't it be great if we had a TWikiRoadMap that could be used for TWikiAdvocacy and outreach?!

So, if I hear no strong reservations in the next couple of days, I'll refactor this topic along lines of the "topic percolation" layout I describe in WikiFacilitation.

In preparation for this shift, I'd also like to present my sense of the group on some key points.

What is the purpose of TWikiRoadMap topic? My sense is that it is to formulate and gather community approval for a concise statement of current TWiki development priorities. I think it's worth reflecting on how this is very different from simply being a place to talk about the need for such a such a document, or a place every individual to simply list their personal wish list. There's nothing wrong with those things as far as they go but this statement of intentions explicitly states that we are committing to the hard work of working past our differences and producing a finished statement that, however imperfectly, reflects a group consensus, and to do so in some reasonable time frame.

What do we mean by a "TWikiRoadMap"? From looking over Crawford's opening statements, a definition of "road map" and a couple of examples of road map documents (Chandler, Mozilla), I offer the following definition for our purposes: TWikiRoadMap is a strategy and planning document for TWiki. It lists the current priorities for improvement and feature development with some definition of sequence and timeframe. The intention is to provide a well-articulated step-by-step plan that, if well executed, will help fulfill TWiki�s mission to gain wide adoption of TWiki.

By when do we want a completed TWikiRoadMap? My sense is that many of us would like it sooner-than-later... like yesterday. On the other hand, I suspect that some people will react to even raising this question... that's it's somehow un-wiki-like. Be that as it may, I really want to see a TWikiRoadMap and am willing to push towards actually having one, if I get a sense some others are willing to go with me. So I propose that we produce the first draft of a group-sanctioned TWikiRoadMap in the next 30 days. If you're strongly opposed to giving this a try, please speak up now. Otherwise, hang on tight!

-- LynnwoodBrown - 02 Nov 2004

As far as addressing "Give broad corporate appeal, without sacrificing above guidelines" goes, I think that PeterTheony's portal as described in TWikiNewsPortal would be a great thing to include in the distribution, along with a cookbook on setting it up.

-- AntonAylward - 02 Nov 2004

Lynnwood, I'm with you. Riding tigers is what I do. Bring 'em on!

-- CrawfordCurrie - 05 Nov 2004

Bill Gates said "When we face a choice between adding features and adding resolving security issues, we need to choose security". Regardless of how well Microsoft has followed that, our road map needs a similar statement. We shoudl avoid the creeping-featuritis and concentrate on some key issues.

Performance is one of those.

Consolidation and simplicification is another. Other threads are already begining to identify where the functionality of various plugins is redundant and could be consolidated. (And considering the overhead of each plugin, this may be a performance boon as well!)

What "adds value"? See TWikiWhatWillYouBeWhenYouGrowUp for some thoughts. What is "cool" and "fun" for coders is not always what sells. Applications sell. Yes, TWiki has plugins that have allowed people to build applications ... but ... those are not applications. At the very least we need cook-books and detailed examples. Even better would be to have the ConsultantsForHire realte what applications they work with and put up demos.

-- AntonAylward - 05 Nov 2004

From Innovation management: models and strategy

• Prof. Dr. Ir. K. Debackere
• K.U. Leuven

http://www.econ.kuleuven.ac.be/tew/academic/strateg/Students/Courses/PartII.Sheets2004_2005.ppt:

1. All Designs have shelf-lives - the technologies in the typewriter were not sufficient to meet the demands of the user base.
2. Dynamic portfolio approaches:the roadmap ...
   • Roadmaps are instruments to integrate business unit strategies and corporate technology strategy
   • Roadmaps have a dual function:
     • linking technology to the business unit by improving/diversifying product/process platforms
     • stimulating the creation of new businesses
   • Developing roadmaps is not a top-down exercise �only� but requires active bottom-up participation and cross-functional processes
3. Roadmaps require ...
   • Cross-functional integration and planning
   • An ability to balance (future) vision and present reality
   • An ability to combine re-active and pro-active thinking
   • Transparency of information and decision processes
   • Improvement of interface management at: * the organizational level (B.U. versus corporate) * the functional level (marketing, R&D, manufacturing) * the competence level (fundamental research areas, development, engineering disciplines, �)
   • A continuous process of planning, combining FIT as well as STRETCH with respect to platform-definition and technology development
4. Roadmaps allow for ...
   • Development of a common language
   • Planning and vision building
   • Identification of generic technologies
   • Establishing a common product-technology strategy
   • Timely availability of new technology (internal or via partnerships)
   • Detection of inconsistencies
   • Supporting the budget cycle
   • Benchmarking against �best in class� as well intra- as inter-company

• Those who don't keep up lose.:
  

-- MartinCleaver - 05 Dec 2004

First of all, I'd like to apologize to everyone who has lent support to this discussion for my not attending to it for the past couple of weeks (and blowing out the timeframe that I set for it :roll: ). My attentions were diverted some by the TWikiSecurity discussions but, more significantly, by a bad cold laying up my son, then my wife, and finally me (ain't that the way it goes). Add a few more days for travelling without internet access...

I'll admit also that I've also had some doubts in the the future of this discussion for a couple of reason which I'd like to share. The first (and less significant) factor in this was the attention going into PersonalTWikiRoadMaps. Don't get me wrong: I've enjoyed reading them and really appreciate the excellent thinking and flavor of individual perspectives contained in them. I've tried as best I can, to plum key ideas from those and add them to the brainstorm list above. My concern was that this seemed to support my general thesis that the "divergent" tendencies of wiki-based conversations more-often-then-not trump "convergent" tendencies. (I wrote more on this here.) In other words, we're good at splitting hairs and not so good at building consensus. We could all list our individual visions but the sum of these will not add up to a shared vision.

My second and more significant concern is the lack of support (or any reaction for that matter) from key members of the core team. Granted, there's been more pressing matters to attend to in the past few weeks, but how long does it take to respond to a poll? I have made direct requests for feedback and so far have only had one response (THANKS SVEN!!!!). I've tried to figure out what this is might mean but, of course, this is a pointless excercise. The bottom line is that, without endorsement and involvement from the leadership of the TWiki development community, I'm not sure what purpose our effort here will serve in the end. I'd welcome other peoples thoughts on this.

All that be as it is, I'll do my best to stand by my promise to move this conversation forward. I still believe, as I know others do, that a TWikiRoadMap would help rally the TWiki community and new recruits to our effort.

-- LynnwoodBrown - 08 Dec 2004

I see the PersonalRoadmaps as a "I want to work in this stuff, and to explore if this is possible", and then those should be checked agains both the TWikiMission and the TWikiRoadMap.

Currently we're working in anarchy (that doesn't mean that's not a good thing, BTW). Each one is doing whatever he what to do. In the furure this trend will continue, as this is the nature of OS projects (we're a Bazaar after all), but the TWikiRoadMap will give the people a guide so they can choose to work in whatever is already stated as a need for TWiki.

OTOH, the lack of "support" from the CoreTeam is understandable. RichardDonkin just recently started to be "active" again and has been busy with the Security issues. SamHasler has been busy with the new forms in Codev, ArthurClemens has been pretty much silent these last two months, and PeterThoeny has been busy with the security issue and being flamed by nearly everybody for his lack of support to the TWikiCommunity.

I would say, give them another month (like end of January) so they are more free to comment.

Anyway, let's tag this with PeterPleaseComment

-- RafaelAlvarez - 09 Dec 2004

See WhatIsIn04x01 for a mini-roadmap-to-be for 4.1.0.

-- SteffenPoulsen - 30 Jun 2006