On Thursday, 21 February 2013 at 15:12:40 UTC, Samuel Lampa wrote:
I think I might see something of what you mean.
For example, the highly successful (not the least in terms of
ecosystem) Drupal project, has many subprojects, for improving
things around Drupal (specific set of modules/plug-ins/project
infrastructure and many other things), which are organised as
groups on their group-discussion site (powered by the "organic
groups" drupal module, which is highly suited for this kind of
self-organizing groups).
http://groups.drupal.org/
(Anyone can start a new group, to facilitate community
self-organization)
You mentioned the main criteria, to get something such to work.
which not many systems have, namely making it easy to keeping
track of who is interested/involved in what, in order to
efficiently interact with the relevant sub-group of the
community.
What D has in this area, seems to be the DSource website, and
forums:
http://www.dsource.org/forums/
I don't know how it works out though (haven't participated),
but it turns out that the above feature is missing: It's not
easy to keep track of who are involved (subscribe to) in
projects. Also, it could maybe be made easier to find for
newcomers?
(Maybe Drupal with "organic groups" could be used to set up an
improved group discussion site? :) )
Cheers
// Samuel
The groups do not seem to be hierarchical based but just a linear
collection. Any method that just uses a linear collection is bad
because the project can't be logically divided into smaller
chunks in a uniform way(in a way that is uniform across the
software and logical to the user). Essentially the drupal groups,
as I have just looked, is a collection of projects in a list but
each project is not a collection of sub-projects and there is no
commonality between all the stuff I talked about before(forums,
users/collaboration, etc...)
I am not sure about gerrit as I've just looked at it but best I
can tell it is just a simple review tool. What I am talking about
would have code review built in but the main thing is the
hierarchical design which allows projects to be divide into
sub-projects and tasks which users can dig down to what they want
to contribute at(from the overview design of a project to a
single line of code) but there is a logical separation as
children can't (necessarily) see parents(although you will need
the ability to have non-parental dependencies).
I think the most important aspects is the hierarchical nature and
the commonality of nodes(All being project based and having the
exact same interface for the user: project forums, collaboration
tools, overview of child projects, etc).
The hierarchy not only allows one to quickly find any sub-project
and project area(e.g., it categorizes projects) but also allows
one to sort of "build" the whole D structure using scripts on
each node(maintained by the maintainers of that node). Each node
into the tree will push it's changes up to the parent node and
the maintainers can accept those pushes which will chain finally
to the root node which will be the current snapshot of D.
The easy of use comes from the tools and user interface(I'm
thinking more of a like project tree diagram.
Test builds could be carried out by individuals relatively easily
by "downloading" the whole D hierarchy(for arguments sake). If
I'm trying to implement a GC for D I could write my own(or fork
another) and then build D using that GC and it will be integrated
in automatically(or easily, unless errors). One wouldn't need to
compile all of D, only what changed, which would be only your
project, so it would be quick). Of course, if all you are working
on effects the D compiler you could terminate the build process
earlier(for slightly quicker results and possibly smaller
footprint on the download).
