You mention 3 lists a number of times, but I thought there were 5: CX: Managed C++ and C# issues VB: VB.NET Issues CLR: CLR Specific issues WINFORMS: Windows Forms WEB: Web Forms, Web Services, etc.
Also, any chance we'll get to see the DATA mailing list? I think that there is enough traffic on the existing list that is specific to data access and XML that it would be worth another list. I know I am biased because ADO.NET has been my life for 18 months. But by the sheer volume of e-mails that my rules split out of the main DOTNET list that are ADO.NET/XML specific, I think there is more than enough call for a separate list. Thanks, Shawn Wildermuth [EMAIL PROTECTED] > -----Original Message----- > From: The DOTNET list will be retired 7/1/02 > [mailto:[EMAIL PROTECTED]] On Behalf Of Mike Woodring > Sent: Monday, June 03, 2002 3:48 PM > To: [EMAIL PROTECTED] > Subject: [DOTNET] Administrative Announcement - Reasoning > > > 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.
