+1 on hating newsgroups. I have received
negative feedback on them from people. I for one have a low appreciation for
them. I spend a lot of my time in e-mails and would prefer to get more
immediate notice of traffic on our newsgroup. Otherwise, I don’t go
check.
I think it would be a huge help to the
community if we had the now standard on-line forums instead similar to what
exists on SourceForge. Then people can choose to monitor them and get e-mails
when traffic occurs. They are much more searchable too and people can create
links to topics from outside. They’re all good.
BTW, I’m becoming a big fan of Drupal
for website management (I’ve just starting using it for Wascana). It has
a Forums module (which I seen but haven’t tried yet).
But, yeah, that’s pretty off topic…
From: eclipse.org-planning-council-bounces@xxxxxxxxxxx
[mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx]
On Behalf Of Gaff, Doug
Sent: Wednesday, October 03, 2007
2:20 PM
To: eclipse.org-planning-council;
Cross project issues; Denis Roy;
Mike Milinkovich; emo@xxxxxxxxxxx
Subject: RE: [eclipse.org-planning-council] eclipse.org server
usage patternsversus new innovative tools
Sorry…this isn’t
exactly on topic….
Has anyone heard
complaints about having to use newsgroups? I have one project lead who
really hates them. It’s true that they are a little “retro”,
but I haven’t heard anyone else complain about them before now.
Doug
From: eclipse.org-planning-council-bounces@xxxxxxxxxxx
[mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx]
On Behalf Of Bjorn Freeman-Benson
Sent: Wednesday, October 03, 2007
12:38 PM
To: Cross
project issues; eclipse.org-planning-council;
'Denis Roy'; Mike Milinkovich; emo@xxxxxxxxxxx
Subject: [eclipse.org-planning-council]
eclipse.org server usage patternsversus new innovative tools
Planning Council, Cross Projects List, EMO,
The eclipse.org IT infrastructure (cvs, svn, bugzilla, wiki, eclipsecon, etc)
is designed to support current usage patterns and expected growth to those
patterns. Innovation in frameworks and tools can affect those usage patterns. I
think we should write up a policy for how Eclipse projects should assist the
EMO in planning for usage pattern changes.
For example, our CVS system is designed around the historic usage pattern of
developers syncing up with the HEAD, doing some work, then committing their
changes, iterating a few times a day, maybe a dozen times a day. But what if
the Team-CVS project team wanted to include a "automatically check for
changes" feature in the Team-CVS code. If the automatic part ran
frequently (every few minutes), this might impose a large load on the
eclipse.org CVS servers and bandwidth - a dramatic change to the usage pattern.
And yet we don't want to discourage innovation like this because it could be a
great feature for end users.
We (the EMO) would want to be involved in design decisions so that we can
understand what the usage pattern changes and their impacts will be. And we'd
like to be involved in web-api design so that there are ways for us to throttle
back the bandwidth/resources at critical times (e.g., the big June release and
the last week before EclipseCon). For example, the hypothetical Team-CVS
feature could utilize a reply code from the servers to throttle back how often
it checks for updates. Etc.
I've started a wiki page for comments: http://wiki.eclipse.org/Eclipse.Org_Usage_Patterns_Policy
- Bjorn
|