Some subjective requirements for a radically optimistic "Code-Wiki" (was: Re: bugs on mantis: who assigns them ?)

Markus Gaelli gaelli at emergent.de
Wed Mar 8 15:05:12 UTC 2006


Hi folks,

I am still waiting for a radically optimistic "wiki like"  
environment, where anybody (ok, say having at least the status of an  
apprentice on Squeak-People...) can change code of the current  
golden_and_shared_image anytime, ideally _always_ developing with it  
as the base for his (do we have a she on Squeak-People with at least  
apprentice status?) daily work.

A first rough description for a simple code-wiki architecture I'd  
like to use:
=============
1.) Some sandbox
	E.g. Accessing the file system from code that gets pushed into my  
image is a big no.

2.) Wiki features: Login, History, Changes, Rollback, Links To
	- Login with squeak-people account
	- Automatic versioning of methods and classes: When I save a method/ 
class in my browser, it gets stored as a new version in the central  
repository. (a tweaked squeaksource?)
		The new version is only pushed into other clients, when I release  
the package it resides in. (see 3.)).
		Other people can see it though if they browsed "versions" of the  
class/method.
	- History, changes and rollback of methods, classes and packages (or  
PackageInfo's as they somehow call them today)
	- Links to: Who needs that
		method, class, package

3.) Difference to wikis or Envy
	- A package knows whether it belongs to the _golden_and_shared_image  
or not
	- Packages do not get versioned, they only get released. As an  
airline company told me recently about my ticket: "Use it - or lose  
it" ;-)
	- Methods and classes get versioned automatically each time one  
changes/saves them, but they do not get released.
	- Methods and classes know whether they are part of a released package.
	- If a package gets released
		- it automatically gets a unique release id
		- it internally stores all release ids of all required packages  
(thus serving as some kind of loadable "config map" at the same time)
		- it gets pushed to every client using the shared environment (only  
if it belongs into the _golden_shared_image_ of course)

4.) A Notion of quality
	- Having the idea that any apprentice could push a new release of  
some package into my current image might naturally lead to more test  
awareness.
	One could think about being able to release a package only if
		-at least all changes (to start from somewhere) are also covered by  
a green test.
		-all tests of all _depending_ packages also still work, whether  
they are in the _golden and shared_ image or not
	-The more a package is down to the system, the more other packages  
will depend on it, and the higher the status (apprentice, journeyer  
or master) of the changing person must be.
	-Having the notion of package ownership the owner shall definitely  
at least automatically get a mail, if a new version of his/her  
package was released

PLEASE: Feel free to play with these ideas (or feel free to let your  
students play with it) or even implement them- I didn't even have  
time to write them down... ;-)
There are some efforts to do sth like that in Croquet I have heard,  
but I don't know anything specific....
===================
Btw: Ward Cunningham is working for the "Eclipse committer community"  
and not for MS since Oct 2005:

"To date, the efforts of the Eclipse Foundation in support of the  
committer community have been primarily around providing  
infrastructure and process. However, a high functioning committer  
community is about more than just sharing servers and following a  
common process. A high functioning committer community is about  
collaboration and cooperation between the project silos. Although the  
Councils do an admirable job of co-ordinating the activities of the  
many Eclipse projects, what is needed is a culture of collaboration  
and cooperation. This is especially true today, as Eclipse grows  
rapidly with new projects and new committers.

To help cultivate this committer culture, Ward Cunningham is joining  
the Eclipse Foundation as Director, Committer Community Development.  
Ward's track record of invention in areas such as wikis, patterns and  
agile development are known worldwide. His current interests in open  
source and developing communities of developers are a perfect match  
for the work we need to do at Eclipse. Ward will lead the effort to  
create a more cohesive Eclipse committer community by working with  
developers in order to enhance Eclipse as "the place to be".

http://www.eclipse.org/org/press-release/20051019cunningham.html

So let's be faster than them :-)

Cheers,

Markus


On Mar 8, 2006, at 1:37 AM, Alan Grimes wrote:

> Here's what I do when I find a bug in squeak:
>
> 1. 90% of the time fix it myself without telling anyone, the rest I
> can't fix and I try to report...
>
> 2. I play around with squeak's built-in reporting system and get  
> yelled
> at to post it on Mantis instead...
>
> 3. Scratch my head and wonder what a carnivorous insect has to do with
> my bug...
>
> 4. Wait 4 days...
>
> 5. In the middle of a dream, while my mind is making random
> associations, that mantis is actually squeak's bug tracking system.
>
> 6. go to one of the well known squeak sites such as squeak.org looking
> for a convenient link to the site. -- which fails...
>
> 7. google the damn thing yet again... (except that I'm beyond  
> caring at
> this point...)
>
>
> -- 
> Don't let your schoolwork get in the way of your learning.
>
> http://users.rcn.com/alangrimes/
>




More information about the Squeak-dev mailing list