NNTP server (news.mozilla.org) needs user support newsgroups

RESOLVED FIXED

Status

mozilla.org Graveyard
Server Operations: Projects
RESOLVED FIXED
13 years ago
2 years ago

People

(Reporter: moz.champion, Assigned: justdave)

Tracking

Details

(URL)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113

Currently, the user support newsgroups are on secnews.netscape.com, which is not
controlled by Mozilla.org, and may be terminated by AOL without warning to
Mozilla.org. The user support newsgroups should be on the Mozilla NNTP server.
This would also help keep end-user traffic away from the development groups.

These groups should be noted as being monitored by the Mozilla Champions and
subject to
newsgroup posting guidelines
<http://mozillachampions.mozdev.org/guidelines.html>  expressly


user.firefox.windows
user.firefox.mac
user.firefox.unix
user.general
user.mozilla.windows
user.mozilla.mac
user.mozilla.unix
user.multimedia
user.thunderbird.windows
user.thunderbird.mac
user.thunderbird.unix 

Reproducible: Always
Steps to Reproduce:

Updated

13 years ago
Depends on: 62228

Comment 1

13 years ago
The plan we have for adding groups is Gerv's outline from several years ago:
  http://www.mozilla.org.uk/newsgroups.txt
(from bug 62228)

It does need to be updated to accomodate Firebird et al. Gerv, you may want to
look at the proposal here and update the mozilla.users.* hierarchy in the plan.
(The mozilla.dev.apps.* hierarchy needs an update, too.)

wrt guidelines, I think staff@ would need to explicitly ratify the no-trim
policy as that conflicts with the policy on all other mozilla groups.
Blocks: 62228
Status: UNCONFIRMED → NEW
Depends on: 215294
No longer depends on: 62228
Ever confirmed: true
All the new groups will be bi-directionally gatewayed to mailing lists, and so
mozilla.org's sensible trimming policies should apply to them all (as far as any
posting policy can ever be said to be "applied").

Gerv
(Reporter)

Comment 3

13 years ago
(In reply to comment #2)
> All the new groups will be bi-directionally gatewayed to mailing lists, and so
> mozilla.org's sensible trimming policies should apply to them all (as far as any
> posting policy can ever be said to be "applied").
> 
> Gerv
> 

in tech help groups it is of great assistance if no trimming is done. Otherwise
to see what has been suggested previously, or done, or asked, it requires
re-reading of each and every message.  When you read up to a 1000 posts per day,
the no trimming saves an incredible amount of time and effort. Trimming would
result in a workload of (on average) ten times that being expended now with  no
trimming

If its the mail lists that mandate this, then remove the groups from such, make
them newsgroup only with no mail list. Is that doable?

Comment 4

13 years ago
(In reply to comment #3)
> (In reply to comment #2)

Also note that Mailing list readers will have the same problem as newsgroup
readers.  If technical content is snipped, the postings can be meaningless.

Comment 5

13 years ago
The problem is that we must be courteous to the mailing list subscribers. In
order to do that we must snip accordingly. We were never faced with this in the
secure groups simply because there was no mailing list.

But the problem with snipping is that users don't snip equally with some users
snipping to a point that only the OP can understand what's going on.

I think the best thing to do is to edit the guidelines to say that snipping is
ok if good snipping practice is followed. We're faced with a new challenge -
usenet and mailing list.
>user.firefox.windows
>user.firefox.mac
>user.firefox.unix

Considering that our apps are cross-platform, especially in their end-user
featureset, this seems like an unnecessary and harmful division of users into
platform-specific groups.  At the very least, a non-platform-specific group
should exist alongside these for discussion of the many non-platform-specific
issues.  A better approach is to create only the general group until the need
for platform-specific groups becomes clear and pressing.

>These groups should be noted as being monitored by the Mozilla Champions

Note that any such official notation needs prior vetting by mozilla.org staff.

Comment 7

13 years ago
A better approach is to create only the general group until the need
for platform-specific groups becomes clear and pressing.

That's why

> user.general

is in the list of proposed groups.

You have a clear cut living example of why the groups should be split from the
start. See the groups already in place on the secure server. This outlay has
also been in place for quite a long time for the Communicator groups where it
worked very well and has a proven track record of support for the different
platforms.

> Note that any such official notation needs prior vetting by mozilla.org staff.

Already taken care of. This is why the Mozilla Champions was created in the
first place. The idea was presented to Mitchell Baker, the resulte being that
Bart was notified to handle it.
(Reporter)

Comment 8

13 years ago
There already exists a clear and pressing need for platform specific groups.
Would  HD/User/<name>/Library/Mozilla/Profiles/<name>/random.slt mean anything
to most Windows folks?  Handling of plug ins is also completely different
between the platforms.  DLL   means nothing to a Mac user for example, it simply
isnt in their lexicon.  The means of choosing which mail apps are in use (with
Firefox) is also entirely platform specific.
Most end users on the mac have no idea of what you are talking about when you
say directory, because its not expressed that way on the platform. Even the
locatioon of the program itself is completely different.  References to Quick
Launch, shortcuts, program directory, txt, doc (in fact most file suffixes) are
completely foreign to Mac Users.
Yes the underlying program is quite similar on all platforms, but in areas where
the system interacts with it, they are often quite distinct.
The newsgroups are geared towards end users, not developers or programmers. Most
end users dont know (nor care if it comes to that) about how the underlying
program does its magic, they simply want to know the easy way to fix a problem.
And to do that, you have to explain in terms they use and understand.
Newsgroups should start with mozilla.* because they would potentially be fed on
usenet and groups like user.multimedia would have no meaning in this context. I
would replace "mozilla" as a product by "mozillasuite", ie :

mozilla.user.mozillasuite.win32
(In reply to comment #9)
> Newsgroups should start with mozilla.* because they would potentially be fed on
> usenet and groups like user.multimedia would have no meaning in this context. I
> would replace "mozilla" as a product by "mozillasuite", ie :
> 
> mozilla.user.mozillasuite.win32

This was discussed in the champs mailing list. (are you not getting messages
from the list?)
The list of newsgroups proposed is a in addendum to whatever the hierarchy is.
For instance, if these groups were to be added to the current list, the full
name would be netscape.public.mozilla.user.firefox.windows. (or remove
'windows', depending on what's decided regarding platform specific groups.)

That's why this bug is intertwined with bug 62228. We can focus on the user
group names, without having to worry about bug 62228.
The champs internal mailing list isn't public, Bugzilla is, that's why it was to
be recorded here. 

Comment 12

13 years ago
Another good reason to ID the groups by OS. If all you have is a "general"
group, there are a lot of users that do not indicate their OS or platform in the
body of the message although that information is included in the header
information. When reading and/or replying to thousands of messages on a monthly
basis that can become an annoying hinderance to effective support.
> > > These groups should be noted as being monitored by the Mozilla Champions
> >
> > Note that any such official notation needs prior vetting by mozilla.org
> > staff.
> 
> Already taken care of. This is why the Mozilla Champions was created in the
> first place. The idea was presented to Mitchell Baker, the resulte being that
> Bart was notified to handle it.

I talked to Bart, Mitchell, and Asa about this, and our plan is to put together
a group of end-user newsgroup monitors/moderators which includes individual
members of the Champions as well as other members of the Mozilla community with
the aptitude and interest in doing this work.

We're happy to have the Mozilla Champions involved in the effort and to give
moderation privileges to those members of the Champions who meet the criteria,
but mozilla.org does not recognize the Mozilla Champions as the official
moderators/monitors of the end-user newsgroups, as we plan to compose such a
group ourselves, drawing upon qualified individuals from the entire Mozilla
community.

Comment 14

13 years ago
> but mozilla.org does not recognize the Mozilla Champions as the official
> moderators/monitors of the end-user newsgroups

This is contrary to the reasons initially given by Mitchell and Bart as to the
formation of the Mozilla Champions in the first place.

However, be that as it may, we're happy to be a part of the community in any
capacity, no matter as a group or individually as the case may be.

Also, I can't think of a better group of individuals, some having over 9 years
of experience in the formation, creation and handling of "user" groups re;
secnews.netscape.com
As for newsgroup names, we have a plan for those, although (as you know) it's
out of date. 

If the criteria for progressing bug 62228 are met (i.e. an admin steps forward),
then we'll look at that list again and have a public debate about updating it.
Until then, I can't see much point in further discussion - unless I've missed
something.

Gerv

Comment 16

13 years ago
Gerv: You haven't missed anything, thanks for the clarification. We'll wait.
(In reply to comment #15)
> If the criteria for progressing bug 62228 are met (i.e. an admin steps forward),
> then we'll look at that list again and have a public debate about updating it.
> Until then, I can't see much point in further discussion - unless I've missed
> something.

Does a news admin have to be on board before the user support group names are at
least be discussed, and (what am I thinking) actually agreed on?

If there is *anything* the rest of us can do "in the meantime" to help this bug,
please tell us.
There's no point in even discussing the names without an admin, because if no
admin turns up, everyone will have wasted their time, because when and if an
admin _does_ turn up, we'd need to discuss the proposal again.

Let's do it all at one time, when we actually know that the plan has some chance
of happening.

Gerv

Comment 19

13 years ago
Agreed.

If "I" were the recently hired Admin, I'd be quite upset that I wasn't included
in the discussion.

Comment 20

13 years ago
I'm no god of newsgroup naming, but here's my two cents. Probably the first
thing to be decided is whether to support or discourage other USENET sites from
carrying the groups. If you want to support this, then it's fairly important to
group everything under a single top-level hierarchy such as "mozilla". A second
top-level hierarchy named "users" is going to be annoying to the rest of the net.

Assuming everything's grouped under "mozilla", I'd lean towards something like this:

mozilla.devel.*           // or "development" or "developers"
mozilla.web-devel.*       // or "web-development" or web-developers"
mozilla.firefox.*
mozilla.thunderbird.*
mozilla.suite.*           // or "mozillasuite"?
mozilla.org.*             // Groups about the organization
mozilla.announce          // and jobs, advocacy, etc.

The key points here are:

1) There's no "users" categorization as such; mozilla.firefox etc. are all for
user discussions. We could group these under mozilla.users, but I personally
don't see much benefit (Actually, I think having a "users" hierarchy next to the
"devel" hierarchy will just help ordinary users notice the "devel" hierarchy,
which something we don't want).

2) The development hierarchy is "devel" or something longer. I feel "dev" is too
short an abbreviation.

The existing proposals, such as http://www.mozilla.org.uk/newsgroups.txt, fit
under this organization pretty easily.
(Reporter)

Comment 21

13 years ago
since Mozilla.org doesnt own the server, nor control it, naming converntions are
up to the discretion of AOL/Netscape

You will note that the firebird group still has that name, and not the updated
firefox nomenclature

The original intent of the bug was to encourage the formation of such groups on
a Mozilla.org controlled NNTP server. And since this bug has effectively been
put on hold until someone steps forward to be a news admin, discusssion about
name and organization of groups is rather moot at this point.

Its no use discussing the various names of groups if you dont have a server to
put them on.
(In reply to comment #20)
Kenneth, your comment really belongs in bug 62228 .
Reassigning to default owner/qa on endico's open bugs so I don't have to watch
her to get mail on them.
Assignee: endico → myk
QA Contact: myk → justdave

Updated

12 years ago
Blocks: 288105
Assignee: myk → justdave
Component: Server Operations → Server Operations Projects
QA Contact: justdave → justin
Depends on: 173864
No longer depends on: 215294
No longer blocks: 62228
Depends on: 62228
No longer depends on: 173864
Although the entire transition of newsgroups to the new hierarchy is not complete, the creation of the user support groups is done. They are up and running on news.mozilla.org; so I would consider this bug fixed.

I don't have permission to mark this bug as FIXED. Anyone want to do the honours? :-)
Yuppers, the support groups are in place.  If we need more, file bugs for individual groups.
Blocks: 62228
Status: NEW → RESOLVED
Last Resolved: 11 years ago
No longer depends on: 62228
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.