[vagueware] Some clarification (LONG!)

  • From: Paul Robinson <paul@xxxxxxxxxxxxxxx>
  • To: vagueware@xxxxxxxxxxxxx
  • Date: Wed, 15 Sep 2004 16:56:13 +0100

It's pretty clear the plans for VagueWare are about as clear as mud. This is 
entirely my fault by dragging people along with ideas of multiple 
abstractions. It's time to clarify. This might muddy the waters. It's also 
very long and takes into account the order I intend to write the code in, so 
please read EVERYTHING before commenting I've left something out in v0.1 that 
you want to see, espeically if that doesn't appear until v0.3 :-)

v0.1 of the new VagueWare code is going to look like the below.

If you are an idea-creator:

- You have an idea you want people to develop
- You start a wiki with an outline
- Other people can revise it, edit, add to it
- There is a "back-channel" where you can discuss ideas with people interested 
in it
- You draft, re-draft, you take suggestions, you edit and review other 
people's edits
- You get into a form that is "publishable" and push it up for publication
- The wider community sees it, comments on it much like they might a story on 
slashdot or kuro5hin - the core article is not an editable wiki, but a 
"version release" of the wiki article that people leave comments under

You are an idea-browser:

- You enter a site that looks initially much like shouldexist, kuro5hin, et al 
and browse the ideas. You may decide to leave comments on some of them. Some 
of them are asking for further ideas and you can see that there are still 
copies of the article that people are improving in a wiki
- You may dig down into articles that aren't published, mini-wiki subsets that 
need help to get published. You can just browse, or you might add to it.

Imagine at this stage a wiki that is fronted with a traditional site where
"finished" articles appear. The wikis can either be private and only viewable
by you and the site admins, or can be open to a group you invite (colleagues,
friends, etc.), or completely public. When you publish, the world sees it. You 
can use the wiki like a kind of drafting area where you can invite others to 
help build the draft up.

Version 0.2:

We add abstractions. 

You can track finished articles or wikis via a variety of means: RSS feeds;
Web-based tools; an automatic subscription for updates to be sent to you
mailing-list style; an NNTP feed; etc.

You can also have other abstractions instead of a wiki for drafting. One of 
those could be a mind/concept map. This would be particularly useful for 
brainstorming an idea out. However, this is just one idea for an abstraction, 
and a useful one. The fact that down the right hand-side of your article there 
are buttons for you to view the article in a variety of ways, or browsers can 
"subscribe" to the idea via RSS, e-mail, NNTP, etc. just means that people are 
able to engage on their own terms. Your *EDITABLE* abstractions are 
interchangeable - if I edit a mind-map, the changes appear in the Wiki and 
vice versa.

Not all abstractions are editable. Some edit the core article, some add 
additional information to a forum or discussion (e-mail, IRC, etc.), and some 
are just ways for you to view changes (RSS)

Version 0.3:

Templates.

Sometimes people need a sense of direction. So, there can be a template for
the things you need to think about that are section headings in a wiki.  
These might be things like "Existing similar ideas", "Things to do to make it
happen", "Market Research", etc. For now, don't worry about what these
templates are, because the first thing we do is build the tools to allow
people to build their own templates. These templates are in such a format they
make use of all the different abstractions.

These templates are user-defined and can either be private, shared within a 
group, or completely public. We'll put a few sample ones up to get people 
started.

Version 0.4:

Work areas.

Imagine you have your idea factory ticking along, you have a couple of 
versions of your specs published up as articles and you've folded in back a 
bunch of comments made about it and you now want to make it happen. You now 
want an area where you can actually make this thing happen.

So, you integrate the "To-Do" list appearing within your templated latest 
release spec (did I mention templates have the sudden amazing ability to be 
convert into little modules like this when the time comes?) into a little 
project-planner, a gannt chart, a task list for members of the team. You'e 
able to show progress on these tasks, share files, check in pieces of code 
(subversion? cvs?) and other materials, your wiki now is building into a 
powerful piece of documentation about your project.

You now have a wiki that is representing your project. You started out with a 
mindmap perhaps, but now you have forums, task lists, releases of 
specifications, all happening by itself, and all anchored by this high-level 
wiki that serves as an introduction to the project. Some bits are only 
editable by certain people, other bits are automatically generated (%age 
progress figures for example :-) ).

Version 0.5:

Multiple Views.

We have multiple abstractions available already, but now I want certain people 
to see certain things. Project admins/owners can see task lists, delegate 
tasks, etc. The public can see bits of your spec, the entire spec, you might 
have locked them out from being able to edit now, but they can see forums, 
etc.

The front page of the site by now is filling with specs, progress reports, 
release notifications, calls for assistance on early ideas, etc.

At this point, we start considering whether what we have is working, in which 
case it jumps to v1.0, or whether it's a failed experiment, we break out the 
pieces of code we like into another project and carry on there, or just shut 
the whole thing down.

To wrap up:

Is all that making things clearer? Am I muddying the waters? Should I be not
be doing something I say I am? Should I do something in a different order, or
in a different way? Are there any questions? Please, flesh this out. I want
more ideas, more bulk before it goes for publiction back into VagueWare
itself. Unless this is all I need?

For background on timelines - I want to have v0.1 done by the end of November,
with much of my Christmas break being dedicated to v0.2 - at least some
abstractions will be available before Christmas. Once those are done, v0.3 is
a few weeks work, then 0.4 and 0.5 are big jumps. Oh, and the language of 
choice? For simplicity I'm considering using Ruby simply as it leaves me free 
to think about the actions rather than the language, but PHP appeals. Perl is 
not an option for me in this core coding activity, but may get hooked in later 
via abstraction code.

There is a lot to take in here, but I think this is the best way to clear the
confusion. Apologies if I've dragged people into something they thought was
completely different. I'm happy to drop the whole idea and just leave
VagueWare as a big wiki if that is what consensus thinks will work best.

-- 
Paul Robinson

http://vagueware.com/
"The key to creativity is knowing how to hide your sources" - Einstein

Other related posts:

  • » [vagueware] Some clarification (LONG!)