This page is dedicated to the __Goofy-project__, where the possibilities of using a wiki-system, as a software development environment is investigated.

!Name
The project is (temporarily) being named Goofy after the wackie figure in Disney's universe. This name is chosen because it says something of the chaotic nature of the wiki-system.\\
Other name-ideas can be added here.

!Vision
The vision of this project is to make it possible to develop a software project in a wiki-system, where everyone can contribute to the finished software. This would make Mob-development (what is Mob-dev? -- Mobile Development?) truly possible, and perhaps result in better software.

!Develop software by the use of a wiki-system
Many of the features of a wiki-system makes it ideal as a software development tool:
*more people can work on the same project,
*errors (bugs) can easily be corrected by the end users,
*its extremely easy to use, so the concept of Mob-development can actually be made possible.

Todays open-source projects are developed by very few volunteers, because the only way to contribute is through "difficult" systems like CVS, or like this project, through email-contributions.
The chaos this would bring is maybe what is needed to bring the software development just a step forward. (See [Feyerabend|http://www.oreillynet.com/pub/wlg/1151])

To implement this the following features must be added:
*Possibility of correcting code,
*Possibility of testing the implemented code.

I admit that this idea is way out, but just look at how fast and bugfree things like [WikiPedia|http://www.wikipedia.com/] has been developed. Maybe the concepts of that can be used in software engineering to.\\

!Needed features
As a software project is developed the developer first comes up with some ideas, then they develop these ideas, while maybe documenting some of the code. After some development the software is tested and used. The aim of this project is to make it so easy to develop the software, that this can even be done by the end users. To make this possible the following features are needed:
*Possibility of coding directly in a wiki-environment.
*Possibility of compiling and testing the code in the environment (like "preview").
*Tree-like file-system structure. (via left Menu?), possibility to traverse the src code tree. --[Rue]
* ...(Add more) .

----

!A possible implementation
I just stumbled on this page when searching for "wiki code version control" -- yep, same idea! I'm going to try and implement this for an ActionScript library I am developing. I've already created a WYSIWYG Wiki for [http://www.WhatIsFlash.com] (launches Jan 1st, 2003.)

Basically, and as outlined above, this will be a Wiki with a custom editor control suited for code (with auto-complete?). I'm favoring the use of Flash for the editor to make sure its cross-platform (the WYSIWYG Wiki, for example uses a Win/IE only control called htmlArea.)

- Aral

----

!!Discussion

A few thoughts about this:

!What we have:

*easy to use web frontend
*versioned content on a per-page basis

!Suggested:

__Coding directly in a wiki-environment__
* ''editing'' code would mean to have good code editing capabilities within your Wiki
* a balance between ease-of-use and functionality would have to be found so 
 it is on one hand not too minimalistic to be a pain to use and on the other hand it is not 
 the reinvention of a full-featured IDE with their powerful but rather complex functions
** How about an emacs browser mode? Full editing capabilities, although hooking the correct
   code formatting mode into a W3 (or whatever) form editing context may be a challenge.. =)
   --[ebu]

__Compiling and testing the code in the environment__
* ''compiling''/syntax check before beeing able to save a page sounds reasonable but could be 
 a problem if you have to modify multiple files together to be in a consistent state again;
 this leaves only a simple syntax check as a criterium for Saving
* ''testing'' the code: assuming we have something like JUnit test-cases we could run them
 to see whether new code actually breaks anything, if so Saving the page could be rejected
** Have a look at [fit|http://fit.c2.com/], from [WardCunningham|WikiWikiWeb:WardCunningham].\\ ''It's about writing tests that people can read''.\\ Example [here|http://fit.c2.com/wiki.cgi?WhatsWhat], and [here|http://fit.c2.com/wiki.cgi?CalculatorExample] \\ It looks like the ideal tool for Acceptance/Customer tests, where the customer writes tests into html pages, execute and see the result with his browser (green is good, red is bad). \\ Having it integrated into a wiki would make writing the tests even simpler. -- AlainRavet
* testing requires ''executing'' the (untrusted) code on the server with all security
 problems this causes; rights of new code would have to be restricted, but the more you do 
 that the further away from a general purpose coding-environment you get

!Other issues/functions needed:
* what about debugging?
* assigning a label to many files to mark certain releases

Considering this, I think it would be more promising to try finding a good way to 
integrate other content than WikiMarkup, but without trying to be a programming-environment 
(of course this is hardly a vision but rather a revision control system with a discussion 
function). 

-- [Torsten|TorstenH] 2002-12-30