Jim Grisanzio wrote:
Hello All,
The OpenSolaris Project is a monster of a project.
t. By my count we've
got 38 communities, 5 projects, 93 mailing lists
(many of those are the
OSUG lists), and hundreds of blogs. This is
absolutely no way to stay
informed about whats happening in the project, and
where people are
needed at any given time, especially for those of us
trying to work in
multiple areas of the project.
I think that was we really need to keep people
le informed is a weekly
report on the project as a whole. This is the sort
of thing done by a
lot of the larger open source projects out there.
For an example, check
out "The Linux Documentation Project Weekly News":
http://www.tldp.org/ldpwn/20051102.html
I put this out as a request because this is
is undoubtedly a full time
job. The idea would be to produce a weekly spot that
outlined, in a
very condensed form, everything thats going on.
Ultimately, it would be neat to have both a web
eb based report but also
an OpenSolaris PodCast to go along with it, perhaps
picking up Richard
Giles torch and building upon what he started.
This would be a great opportunity for someone who
ho isn't sure how to
contribute but is really enthusiastic. I'd like to
fill this role
myself but just don't have the time.
If you're interested respond to this thread, or
or even better yet, just
go for it and lets see how things go!
Good idea. Happy to help. I think you'll need several people to collaborate on
this, though. It's just too big (and will only get bigger and move faster) for
one person to speak authoritatively about. It would be great to have some
summaries of the mail lists, too.
Summarising the mailing lists would be the primary goal. Aggrigation
via RSS can only go so far, at some point you need an intellegent and
informed human being to summarize mailing list threads, point out
references to work being done, etc.
If such an effort were successful we'd all be "in the know" on a weekly
basis. Right now many of us are only aware of a fraction of whats
underway and where things stand. As a perfect example, the recent
confusion and frustration reguarding SX:CR B33 could have been avoided
is we'd all been working off the same sheet of paper.
Currently, we are welcoming community contributions to the newsletter, which is
monthly at this point. We'd like to grow it substantially. And in the content
project, I'd love to do some multi-media stuff with podcasts (would love some
equipment for that, too :)). I can easily see representatives from multiple
communities/projects getting involved with an idea like this.
Another great example, I have no idea which of Sun's gazillion
newsletters your refering to. :)
There are several ways to approach this, several of which we discussed
this afternoon in IRC:
1) A single individual keeps informed on everything and reports weekly
via report (HTML) and possibly a PodCast. I like this solution only
because it gives everything a single voice and a singular style.
However, its far too big a job for one person unless they really are
willing to take it on as a "full-time" (in the open source sense) job.
2) A centralized report thats updated throughout a given period by
everyone, aka: the wiki solution. In this method we'd create a new Wiki
page every week, which everyone could add to, update, and modify for
that weeks period. On a certain day the page would be closed and locked
out. This relieves the burden from a single individual but allows
things to fall through the cracks. There is no guarrentee that
_everything_ will make it in.
3) The beaurocratic method, weekly reports from every community leader.
Forcing every community to report back to the mother ship every week
would really be a burden I think and asking far too much, plus you'd
have to enforce it and police the reports. Its just a bad idea, but it
should be noted in a list such as this.
4) A small "commitee" of sorts. This is something of a combination of
#1 and #2. You centralize the information on a wiki for everyone to
contribute but assign a group of volenteers as over-seers to check
things and makes sure the cracks are filled.
There are other ideas, but I'll leave it at that for now. There are
several options. Given that this isn't the sort of decision that can be
laid in stone so easily, perhaps we'll start with the wiki solution and
see if it sinks or swims. In the meantime it'd be great to hear other
ideas or find out if any specific members of the community would have a
desire to contribute in this way.
benr.
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
