Thanks for the insight into the decision-making process; I appreciate it.
I still have my reservations about the split, but it does seem well thought
out, and the decisions and compromises seem fair.
As far as Don's predictions go, don't give him too much credit; he has a
hard enough time now getting into his tub--there's hard evidence for this:
how long has it been , in fact, since he's been wheeled onstage to give a
lecture in a tub?
Steve Holak
Senior Software Architect
Brokerage Concepts IS Dept.
610-491-4879
email: [EMAIL PROTECTED]
Mike Woodring
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
OM> cc:
Sent by: The Subject: [DOTNET] Administrative
Announcement - Reasoning
DOTNET list will
be retired 7/1/02
<[EMAIL PROTECTED]
VELOP.COM>
06/03/2002 03:47
PM
Please respond to
The DOTNET list
will be retired
7/1/02
Hi Everyone,
Based on the replies we've received in regards to our decision to partition
the DOTNET list (some of which have been sent privately), I thought I'd
post
a little information on the history & motiviations of the decision, as well
as a few replies to specific comments people have made (in FAQ format)...
* Who was involved in the decision?
Everyone at DM participated in the debate about what to do based on
feedback
we received from our own DM instructor, students, Microsoft dev leads &
PMs,
current list subscribers, and former list subscribers whose contributions
were valued. This discussion was a long, intense debate that spanned at
least 3 months. After weighing all of the feedback, and realizing that no
one decision is perfect, we arrived at this decision; which we felt was
(all
things considered) the best option.
* Why was the list split?
The key issue is degradation due to increased *on-topic* traffic, not
off-topic traffic. Certainly, this list (like any other) suffers from
occassional off-topic posts, which I'll address separately below.
- Degradation due to increased on-topic posts.
This is the form of the degradation that worried us the most - primarily
because it has resulted in the list losing subscribers that previously
contributed to the list in a valuable fashion, but that have since left the
list due to the traffic volume. These people include DM instructors,
Microsoft devs & PMs, and numerous other individuals that previously
contributed in a valuable manner; but that left the list due to increased
traffic.
Brad hit the nail on the head when he pointed out that the quality of the
list is a function of the participants, and not the list host.
Unfortunately, we've seen valuable contributors leave the list due to the
increased traffic. That indicator carried a lot of weight in the decision
making process.
As just one example, one of the things that made this list so valuable in
the early days was the contribution of members of the various .NET
development teams. This list was effectively a direct pipeline into those
teams. Participants could pose questions or bug notes and get replies
directly from the dev in charge of that area. But as traffic has soard,
MSFT involvement has diminished. Please note that Microsoft's involvement
isn't the only involvement we're interested in - it's just a typical
example
of something we've seen and heard about from many people we come into
contact with at conferences, in classes, and through email.
By partitioning the list into more focused communities, we hope to
encourage
those wayward participants to rejoin and further increase the value of the
list to the entire subscriber base. For their part, Microsoft has
committed
to rejoining our new communities as active contributors under the new
split.
We hope that everyone else that has left the list will also be encouraged
to
resubscribe for the benefit of all of us.
- Degradation due to increased off-topic posts.
Any list will suffer some amount of off-topic posts. Options for dealing
with this include do-nothing, hard moderation, or what I call community
policing; where list participants ask people to take off-topic discussions
somewhere else. Hard moderation requires a significant amount of effort,
as
has been pointed out. It's simply not feasible to dedicate one or more
individuals with reading every single post before approving it for
pass-thru
to the list. By partitioning this list into more focused communities,
we're
hoping to find a middle ground by allowing us to task designated DM
individuals with community policing of a specific list so that a minimum
level of monitoring & oversight is ensured.
* What kinds of options were considered?
We considered doing nothing, switching this list to a moderated forum,
splitting the list, and switching to an NNTP solution. As for splitting
the
list, we debated quite extensively what the 'right' amount of lists would
be. We felt one list was deemed unsustainable moving forward, but neither
did we want to create 16 new lists like
DOTNET-WINFORMS, -WEBSERVICES, -WEBAPPS, -XML, -DATA, -SECURITY, -REMOTING,
etc, etc, etc. So when we decided on splitting the list, we spent a fair
amount of time wrangling over the right initial approach.
* The list shouldn't be repartitioned because it wasn't originally.
Actually, the original charter post to this list (by Don Box) indicated
that
we would likely split the list as traffic dicated. Refer to [1] for the
actual post.
* Splitting the list will cause increased traffic due to cross-posts. Also
phrased as "how will people know which list to post to"?
First, DM list monitors will discourage cross-posting to more than one
list.
The entire community is encouraged to discourage cross-posting, but we'll
strive to make sure that there's always someone at DM responsible for
monitoring each list.
Second, we believe there are basically two types of subscribers: those that
will only subscribe to one list representing their area of interest (say,
WinForms apps); and those that want to subscribe to each of the 3 lists and
that will think about which list to post to before doing so.
For the subscriber that only subscribes to -WINFORMS or -WEB, they'll just
post their question to that forum. It doesn't matter if they have a
remoting, security, serialization, or data access question. In many cases,
their problem is influenced in part by the environment they're developing
for, so the
answers differ accordingly. In this case, the community benefits from the
discussion.
For the subscriber that subscribes to all 3 lists (including -CLR), the
choice should also be fairly straight forward. If you have an obvious web
page or web service question, post to -WEB. If you have an obvious
WinForms
question - post to -WINFORMS. If you have a question that you recognize is
generic and applies to all areas of development (CAS, data access, etc), or
where it's not so obvious about where the post should go, the -CLR list was
specifically chartered for such conversations. (Please continue reading
the
next note about redundant discussion before replying to this item :-).
* Splitting the list will cause increased traffic due to redundant
discussions.
Although this might be true to some extent, we believe this is a moot
argument...
First of all, it will not be considered redundant for people that only
subscribe to one list (which we believe will be a larger fraction of the
subscriber base compared to people that will subscribe to all 3 lists).
Second, those subscribers that do participate in all 3 lists, and that spot
a post that's been asked & answered elsewhere, are free to reply indicating
that the question has been covered elsewhere, and to please check the
archives. This is no different that what happens today on the unified
DOTNET list when someone posts a question that's been discussed at length
in
the archives. "Check the archives" community policing will always be
necessary on an unmoderated list. Telling someone to check the archives
for
this list or another list is the same amount of work for the individual
involved. And because the charter for each of the new lists specifically
calls out "check the archives before posting" as part of the posting
guidelines [2], DM's list monitors will more actively enforce this policy.
Finally, we'll be putting a unified multi-archive search engine in place in
the very near future to make it as easy as possible to locate the answers
to
questions that have been previously discussed - no matter which list the
discussion took place in (including the archives for this list, which will
remain forever).
We hope that everyone will recognize that a fair amount of discussion took
place on this issue, that the decision was not made in a vaccuum, and that
it was not an easy decision to make by any means. However, given all of
pros & cons of each approach, we felt this decision was the best one in
order to sustain the continued participation of our current subscriber
base,
recapture the participation of our lost subscribers, and help manage the
future growth of each list -- all of which should increase the value to our
collective community.
-Mike
http://staff.develop.com/woodring
http://www.develop.com/devresources
[1]
http://discuss.develop.com/archives/wa.exe?A2=ind0007&L=dotnet&F=&S=&P=129
[2] For example, see
http://discuss.develop.com/archives/wa.exe?A2=ind0205e&L=dotnetweb&F=&S
=&P=5
2
You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
