Since this is a public list and we are trying to build a generic tool in
order to attract as many users as possible I have removed all references
to specific projects or data sources. The notes here do not superced the
details about data wources and consumers identified in the original
meeting, but they are not appropriate for this list which is for the
discussion of a generic framework for supporting data sharing about
projects.
Summary
Duplication in project data held by the various project registries is to
be avoided and other systems should be able to draw on data held and
produced by any other project registry.
It was felt it would be difficult and inappropriate to attempt to
integrate the data processing and storage mechanisms of all systems into
a single monolithic system. Instead we are to focus on data sharing
where appropriate. the sharing mechanism is to be a central repository
of data from which individual applications can pull the information they
need and new data they generate that may be of use to other projects.
Details
It was observed that most of the represented projects required a common
set of data (programme and project details and participants for
example). It was also observed that some projects were collecting and
generating data and/or services of interest to other proejcts. For
example, Simal is collecting details about software project community
tools such as issue trackers, mailing lists, RSS feeds and version
control systems, whilst other projects were interested in mining these
resources.
The question of whether all the systems should be merged into qa single
system was discussed, and the conclusion was that would probably not be
feasible. Given the different task and information focus of the systems,
such as open source software or process, use case and application
models, and their different scopes, it was felt that their inclusion
would be unmanagable in s ingle system.
Furthermore, somce systems, such as SIMAL take advantage of semantic web
technologies, whilst other systems did not need this overhead and could
operate perfectly well with a standard relational system. This would
make it very difficult, and perhaps inappropriate, to try and integrate
them all into a single system.
Instead it was agreed that there needs to be a mechanism and a
repository through which projects could share data.
That still left open the question of what information, in detail, all
the systems do and/or expect hold, mapping out overlaps and then
determining which will be the core source system for what information
elements.
It was observed that a long drawn out information analysis presents a
number of risks
1. putting everything on hold for an indefinite time
2. developing a long list of information requirements which may in
practice never get used
3. adding additional complexity to individual projects each with
their own delivery schedules.
It was therefore proposed that we should take an incremental (i.e.
agile) and open approach, working from what we have already got. It was
therefore provisionally agreed that interested projects would export and
import DOAP descriptions of projects. This allows us to immediately
identify the common data to be shared and the format to share it in.
----
And so we come to this mailing list. the initial objectives will be for
interested projects to actually start sharing data.
Let the discussions commence.
I'll wait a short while, for people to subscribe as I only just created
the list. Once a suitable representative group are present I will post a
proposal to get us started.
However, anyone is free to start the ball rolling.
Ross