Igor, The Zinc project[1] is a good example. First there is the README.md which introduces you to the project[2]. The README.md is a document (under version control) that can be updated by any member of the development team[3] in the GlassDB organization. The document uses markdown[6], so you get nice formatting and syntax highlighting for your Smalltalk code. You can see the history of the document[5] and easily access diffs (click around on the page). If you have permissions you can even edit the document via your web-browser (useful for minor tweaks). The same set of capabilities also exist for any other text files that you might like shells scripts, makefiles, etc. Smalltalk code can be stored in the repository[7], via FileTree[8]. The README is not the only way to share information. Sven's writeup on Zinc is an additional example of shared documentation. With regards to interacting with real-live code, take a look at the interactions of Paul and I on this pull request[10]. If you click on one of the files[11] in the comment boxes associated with the pull request you can see and example where Paul and I had a small discussion about changes to a particular Smalltalk method.... When Paul submitted the pull request, I made a pass through the changes and commented on each change that I had questions/comments about. Paul was notified of my comments and responded to each one in his own time ... and in some cases I came back and re-responded ... In this particular instance Paul and I realized that because we were seeing to many differences that "didn't make sense" that we were probably integrating the wrong code and ended up deciding to got with a different approach, that resulted in a separate pull request[12] being submitted and merged. Here's the issues list[13]... Some folks use github to host their own blogs as well, although I haven't looked into the details for that. If you are looking for true interaction and collaboration, I think that github is hard to beat.... You do have to learn git to use github and I would not claim that git is easy to learn, but there are lots of resources on the web for teaching you git....if you don't have the time to learn git then that should be a factor, but you should weigh that against the amount of time spent trying to collaborate and the cost of learning git may just be worth it and then again it may not. Dale [1] https://github.com/glassdb/zinc [2] https://github.com/glassdb/zinc/blob/gemstone2.4/README.md [3] https://github.com/organizations/glassdb/teams/ [5] https://github.com/glassdb/zinc/commits/gemstone2.4/README.md [6] http://github.github.com/github-flavored-markdown/ [7] https://github.com/glassdb/zinc/blob/gemstone2.4/repository/ConfigurationOfZ... [8] https://github.com/dalehenrich/filetree [9] https://github.com/glassdb/zinc/blob/gemstone2.4/zinc-http-components-paper.... [10] https://github.com/glassdb/zinc/pull/1 [11] https://github.com/pdebruic/zinc/commit/5f09f70ba9abab24314ac8ed5e6cba668ac7... [12] https://github.com/glassdb/zinc/pull/1#issue-ref-16577627 [13] https://github.com/glassdb/zinc/issues?page=1&sort=updated&state=open ----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Monday, July 30, 2012 10:55:13 AM | Subject: Re: [Pharo-project] Going meta (VM development) | | On 30 July 2012 17:59, Dale Henrichs <dhenrich@vmware.com> wrote: | > | > | > ----- Original Message ----- | > | From: "Igor Stasenko" <siguctua@gmail.com> | > | Another thing, which i discussed locally , i thinking about | > | creating | > | a | > | dedicated blog for VM developers, where we can share the news and | > | describe | > | details about changes and stuff.. | > | In a way, that it will serve as a source of information about VM | > | , | > | jenkins , configurations, settings , building etc etc.. | > | Because all of the bits of knowledge , which we collected till | > | now is | > | kind of floating in the air, and like any energy it tends to | > | dissipate | > | (things we remember and forget, the more things we should keep in | > | head, the faster it happens). | > | Also, blog is preferable to just simple CHANGELOG file (or | > | similar), | > | because it is two-way communication , and people can comment and | > | discuss things. | > | > Igor, | > | > You might find GitHub as a very good place for this. GitHub has a | > number of collaboration features that play very well together: | > | > source code control with git | > issues where you can report bugs, but also host conversations | > wiki for documentation although I like markdown for documentation | > since the docs are then versioned with the code | > | > When you view code diffs you can make line by line | > comments/questions that are visible to other developers who can in | > turn comment on your comments ... talk about real two-way | > communication:) | > | > The real advantage is that all of these things are versioned | > together ... code/documentation/articles ... | > | > Anyway, it's worth considering:) | > | | Hi, Dale, do you have any links, nicely demonstrating the features | you | described above? | For me, as an utterly lazy guy, who also doesn't loves writing much, | the simpler the better.. | that's why i thought about just setting up a blog and posting notes | there, which is just few minutes.. | Throwing git into the cycle would extend this time.. and as result, a | willingness to post about updates.. :) | | > Dale | > | > | > | | | | -- | Best regards, | Igor Stasenko. | |