On 14/08/07, Darius Clarke <socinian at gmail.com> wrote:
> Another "modest proposal" [see link for satire
> http://en.wikipedia.org/wiki/Modest_Proposal].
>
> Perhaps we could include a/the suggestions/bug-fix database as default
> in the code browser itself, by default. Hence, everyone with a browser
> could be updated the moment the twinkling of an idea appears for the
> class one is currently browsing.
>
> However, actual discussions would be linked to appropriate websites
> from the code browser for discussions to be handled there. In this
> manner, the code browser would be the common, universal forum for
> directions and ideas as one is coding in the classes which would be
> the ones potentially influenced/changed by such ideas. Perhaps
> distracting, but until such a form of social programming is tried, we
> don't know if it would be distracting or not to have such things
> represented in a button or highlighted tab away.
>
> Ideally, I'd rather look over coder's avatars shoulders in Croquet to
> look into their "intentions" for "social programming", but Croquet's
> not standard yet nor universally runnable on all graphics cards.
>
> Perhaps, in an effort to leapfrog over "language innovations" for
> other programming languages, we could create a Croquet room where such
> alternative suggested fixes and directions can be showcased, like a
> portrait gallery of code. In this manner, the geographical placing of
> the suggested code changes indicates which part of the
> code-base/class-library would be affected.
>
> Indeed, like Alan Kay suggested many years ago... Smalltalk should
> have eaten its children by now. Maybe social programming (like other
> social web sites) is the way forward. We already agree it's OK to
> scratch ones own itch. Maybe the social mores need to change so it's
> OK to do so publicly, in the code browser.
>
> Darius
>
>
Nice idea indeed! :)
I'm already start thinking about implementing some simple protocol for
interacting with public server. A message protocol can be very dumb
and straightforward, like:

- list class log entries (class, start date , end date).
- list package log entries (package, start date , end date).
- fetch entry by id.
- add class log entry (date, author, type, contents)
- add package log entry(date, author, type, contents)

a basic entry types can be:
- create topic
- add comment to specific topic
- add new delta (also creates topic)
- vote for entry (accept/reject) (you can vote , giving your approval
for some delta, or for someone's point of view).

A voting is good to collect information about what people think of
given update. Then  admin/GOD/package maintainer can simply click
'Approve' or 'Reject' a change. And all users will have a single
button 'Download approved changes'.


-- 
Best regards,
Igor Stasenko AKA sig.