The Semantic Labs

[adrian.brock]

I would like to see a much better metamodel of projects within labs.

To me labs is currently just another location that I have to update
with some poorly semantic markup.
There are already far too many of these with our tools
separated across multiple locations and not talking to one another.
* JIRA
* Sourceforge
* Mailing lists
* Forums (user and dev)
* WIKI
* News
* JBoss.com page
* etc.

I want to be able to maintain a "database" of information
and use "templates"/"rules" from a standard development process
that knows what the information means.

Lets take a simple usecase - a new release.

It should be possible for QA to make a new release
such that it automatically does:
1) Updates the downloads sections on labs and JBoss.com
2) Updates the news sections with some boiler plate text,
a link to the download and copies in the release notes from JIRA
3) Posts the same news to the forums and any mailing list
we have defined for such events.

To make this work, all that QA should need do is enter the identifier of the
release. The rest should comes from rules on how to find the
download, JIRA release notes, the places to notify, etc.

There are other similar processes, e.g. adding links to interesting
articles that would update the documentation page and also post
a news article.

This should require a simple piece of data entry, not the duplicate
maintenance of poorly semantic markup.

[dsicore]

Adrian,

How would you like to see the "data entry" portion take place? i.e., what's the interface? Would you like to see this part of a build process: 'maven release jboss-mc-1.0.5' ? Or do envision QA going to a web page to do a new release?

We have the components required to do what you want to do, but I want to flesh out what you believe would work best for everyone. The interface issues seem to be the sticking points (i.e., "You mean I can't edit my web page by clicking 'Edit' on any given web page?!").

What are some of the other use cases you'd like to see? Here are a few Labs Meta Use Cases I can think of off hand:

* Monitor feedback for any given release (i.e., blog comments [the drools guys want blog comments like crazy], forum posts, bug reports, news posts via aggregated feeds from third parties, etc).

* Show releated JBossON activity for my Project or a given component of my project (i.e., a release, download, or any given item in my CMS)

* Generate documentation for a release. (Another interface sticking point because some people want this part of their build mechanism--so it updates Labs when they build docs).

What else?

Please keep it coming. Semantic Labs is what I've been aiming for all along. :]

Sincerely,

Damon

[adrian.brock]

Adrian,

How would you like to see the "data entry" portion take place? i.e., what's the interface? Would you like to see this part of a build process: 'maven release jboss-mc-1.0.5' ? Or do envision QA going to a web page to do a new release?

You'd need to ask QA. :-)

If there is an http request page that requires authentication, I'm
sure somebody can build an ant/maven plugin that invokes it
with the relevant information.

We have the components required to do what you want to do, but I want to flesh out what you believe would work best for everyone.

I don't think there is one solution. Different projects work different ways.
Though I personally would like to see a minimal set of standard
if only because:
1) It is easier for developers to work across projects
2) They represent "best practices"

What are some of the other use cases you'd like to see? Here are a few Labs Meta Use Cases I can think of off hand:

Don't know off hand. I am a great believer that all data entry
should be "mineable". i.e. If the data enter has enough context
and can be queried then all sorts of unforseen applications
can be developed in the future.
That is why I balked at the plain text/html entry (except for stuff like blogs).

[adamw]

Hello,
as Damon wrote, it's more or less what we've been thinking about for some time :).
The central place for a "project definition" could be project.xml and maybe some assocaited files (managed with a web interface or for fans - in vim ;) ). Many things are already defined there - project name, info, categories, menu, portlets, news feed source, downloads. We could extend it with things like jira address, repository address, and add structured documentation (it will have to be structured so that we are able to dynamically change it).

To be able to "mine" the data, I guess we'd have to restructure&generalize the ProjectDescriptor - and, maybe, write a servlet/web service which would make the data available to other services (however, the data is available anyway in project.xml which is in cms - so widely available)

Another thing that I'm wondering about is if Adrian used the word "rules" accidentaly. I know almost nothing about JBoss Rules, but maybe they fit what we want to do here - that is, have some standard "procedures" - rules sets for common tasks, and if a project has some nonstandard ones - add them as plugins, defined, of course, in project.xml :). It can also be done with plain java files, but maybe it's what Rules are for.

Also, maybe we should make a wiki page with the use cases? Some other things:
- automatic documentation building & publishing
- the same for javadocs
- "snapshot" packages - this could be automatically built and placed for download during the night for ex.

--
Cheers,
Adam