Closed Bug 375879 Opened 17 years ago Closed 17 years ago

Create new mozilla.feedback.* newsgroups

Categories

(mozilla.org :: Discussion Forums, task)

All
Other
task
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: baz, Assigned: justdave)

Details

After discussion with a bunch of folks, we recognize that we would like to have two new USENET groups under the mozilla.* hierarchy as follows:

mozilla.announce.prerelease - Used to announce availability of Mozilla product alpha, betas and release candidates.
mozilla.feedback.prerelease - Used to collect feedback about Mozilla product alpha, betas and release candidates.

These should be gateway'ed and administrate-able via Mailman (lists.mozilla.org) under announce-prerelease@mozilla.org and feedback-prerelease@mozilla.org

The announce list should be created with posting moderation privileges and should be assigned to me and Jay Patel for posting approval.
The feedback group should be postable by anyone.

Let me know how we can get this done, esp. if USENET mozilla.* hierarchy needs separate community approval.

We'd like to have this in place before the Firefox alpha 4.

Thanks.
Group: mozillaorgconfidential
Component-->Newsgroups

Basil, I'm not sure if youre under the impression the mozilla.* newsgroups are fed to Usenet. They are not. They are only on news.mozilla.org and Google Groups. (more info: <http://www.mozilla.org/community/giganews-migration.html>)
Are you saying that you want mozilla.announce.prerelease and mozilla.feedback.prerelease to be exceptions?
Assignee: server-ops → gerv
Component: Server Operations → Newsgroups
QA Contact: justin → justdave
Chris:  No, I think we just want to create those two new newsgroups in the same fashion as the other ones.  My understanding is that we migrated news.mozilla.org from giganews to google a while back... so creating mozilla.feedback.prerelease and mozilla.announce.prerelease in the regular places will be fine.

Is there a reason we never pushed to Usenet?  I don't know much about news servers, so just asking. :-)
Nope, getting on google was part of the giganews setup, we're dealing with both.  The move was moving from AOL to Giganews.
mozilla.announce.prerelease sounds like a fine idea, as long as we are sure that "prerelease" is a general enough term to cover everything we'd want to put in there.

I have a little concern about mozilla.feedback.prerelease. "mozilla.feedback" is a collector newsgroup for the Hendrix web tool; it's not a discussion newsgroup in the normal sense, as I think you want mozilla.feedback.prerelease to be. Therefore, putting it underneath that group might create confusion. mozilla.feedback currently collects feedback from Hendrix on all releases, including pre-releases.

What is the intended purpose of this group? Is it for discussion of, and pointing out bugs in, prereleases? Don't we have groups and mechanisms for that already? 

Gerv
(In reply to comment #2)
> Is there a reason we never pushed to Usenet?  I don't know much about news
> servers, so just asking. :-)

Jay: AIUI, the reason we don't push to Usenet is so that we can delete spam and other things that we don't want there for whatever reason.  Giganews and Google have both agreed to purge messages as requested but it is very unlikely that a news server with which Mozilla does not have a direct relationship would honor such a request.

So, basically it's intentional in order to allow retroactive removal of unwanted messages. (including spam)
The impetus for this request was out of the 2.0.0.2 post morteum where we recognized that we need a way to communicate availability of the Release Candidates (RC), alphas, betas, etc... for point releases as well as major Firefox releases.

The term "prerelease" was meant to cover all of the above.

Community members, corporate users, MoCo/MoFo employees, etc... that want to try out and test early releases can subscribe to this list or read the newsgroup. 

The idea with mozilla.feedback.prerelease is that it's a collection point and discussion location for issues specifically related to these betas. If not mozilla.feedback.prerelease, then where in the hierarchy? Hendix data would continue to flow into these groups as well.
Basil: the Hendrix stream is a firehose - 100+ messages a day. You don't want to be trying to have discussions in a group which is on the receiving end of it. I also think there's value in having all the Hendrix input go into the same group.

I'm not against a discussion group for specific, manual feedback on prerelease builds, as long as we aren't duplicating function or stepping on anyones toes (e.g. MozillaZine's - don't they have a Build Forum?) by providing it. Where does the community currently discuss issues with nightlies and pre-releases?

Gerv
(In reply to comment #7)
> Basil: the Hendrix stream is a firehose - 100+ messages a day. You don't want
> to be trying to have discussions in a group which is on the receiving end of
> it. I also think there's value in having all the Hendrix input go into the same
> group.

We understand this, and that is why we wanted to add a new mozilla.feedback.prerelease group...to separate hendrix feedback for all builds/releases from manual feedback for specific prereleases.

> I'm not against a discussion group for specific, manual feedback on prerelease
> builds, as long as we aren't duplicating function or stepping on anyones toes
> (e.g. MozillaZine's - don't they have a Build Forum?) by providing it. Where
> does the community currently discuss issues with nightlies and pre-releases

I think nightly builds discussions are spread out across IRC and mZ forums... but we don't have any place for prerelease feedback and discussion (necessary for quick review of issues during tight release cycles).  We are trying to create such a place so that noise from nightly discussions don't interfere with specific issues with alphas/betas/rc builds.

Unless anyone has a better suggestion, I think mozilla.feedback.prerelease makes the most sense.  We will continue to point folks to Hendrix for general feedback, but will also suggest to partners and "beta" users to discuss issues in the new group.



(In reply to comment #8)
> We understand this, and that is why we wanted to add a new
> mozilla.feedback.prerelease group...to separate hendrix feedback for all
> builds/releases from manual feedback for specific prereleases.

Right... and my point is that the mozilla.feedback.* hierarchy (someone just requested another group be added to it in a bug which is currently private) is currently for webform-collector feedback, not for manual discussion. I'm concerned that it would confuse would-be subscribers to mix up the two.

It may turn out that this concern is overridden by the appropriateness of the word "feedback", but I'd like to suggest some alternatives first.

> I think nightly builds discussions are spread out across IRC and mZ forums...
> but we don't have any place for prerelease feedback and discussion (necessary
> for quick review of issues during tight release cycles).  We are trying to
> create such a place so that noise from nightly discussions don't interfere 
> with specific issues with alphas/betas/rc builds.

Sure.

How about mozilla.support.firefox.prerelease and mozilla.support.thunderbird.prerelease? There might be value in separating Firefox and Thunderbird pre-release discussion. Were you anticipating your group to be for all pre-releases, including Camino, Seamonkey etc.?

Gerv
I think the word "feedback" is appropriate for what we're trying to do here... more so than "support" (which is not our intention).

I am not too concerned about people getting confused and don't think the auto vs manual feedback should be an issue.  I think most folks that read mozilla.feedback already know that it is mostly auto submitted Hendrix data from the webform, with a bit of manual posts thrown in, including replies and discussions about specific Hendrix posts.  

I personally think that mozilla.feedback should become a more general manual feedback/discussion channel... and we should move Hendrix to something like mozilla.feedback.hendrix.  That way, we can add other communication channels to mozilla.feedback.* for specific breakdowns by products, future webform feedback tools, and migrated data from things like Breakpad or Reporter.


I know that is a huge change, but I think we should consider it.  We just need to educate folks about any changes or new groups we create.  And I believe we will be doing a lot of that for the prerelease groups, so hopefully that will help avoid confusion (even if we don't move Hendrix data anywhere).

I am not sure whether we should create individual channels for Firefox and Thunderbird (and other Mozilla project products)... that's a tough call.  What do you think Basil?

This might be a good discussion for the newsgroups, not Bugzilla...
If you want to post a proposal in mozilla.governance, that would be great.

My suggestion: "mozilla.feedback.hendrix" encodes an implementation detail into the newsgroup name. It would be better to start dividing the feedback up by product (thereby reducing the volume in any one group). So:

mozilla.feedback.firefox
mozilla.feedback.thunderbird
...

Then, to be more specific, we could do:
mozilla.feedback.firefox.prerelease
mozilla.feedback.thunderbird.prerelease
and you have the groups you wanted.

I would be happy to make the Hendrix changes necessary to support this.

Gerv
cc'ing Sam Sidler and JT Batson (he's putting together a customer service strategy for Mozilla).  

Gerv:  I think you're proposal in comment #11 is our best bet.  Can you please post that to the governance channel?  If there is no objections, we should finalize the changes and make them official.

We should just point Hendrix feedback to the appropriate product feedback channel (e.g mozilla.feedback.firefox) and encourage more collaboration and communication there... and not worry too much about mixing manual feedback with web-form feedback (all types of user submitted information is feedback, so there is no point in separating them by channel, a simple [hendrix] in the subject should be sufficient).  

Sam brought a good point in that most current feedback is probably support related... so we need to figure out how to redirect those posts to the correct forums/channels for support... and hoping the stuff JT is working on will help us do that.
(In reply to comment #12)
> Gerv:  I think you're proposal in comment #11 is our best bet.  Can you please
> post that to the governance channel?  If there is no objections, we should
> finalize the changes and make them official.

Will do very soon. I just need to see if another private bug can be opened, as it's relevant to the proposal.

> web-form feedback (all types of user submitted information is feedback, so
> there is no point in separating them by channel, a simple [hendrix] in the
> subject should be sufficient).  

OK.

> Sam brought a good point in that most current feedback is probably support
> related... so we need to figure out how to redirect those posts to the correct
> forums/channels for support... 

There's a clear message with a link on the Hendrix front page. If they ignore that, there's not much else we can do.

Some community members do dip into the Hendrix pool and offer advice to some of the more polite-sounding people. :-)

Gerv
There were no objections to my proposal, and the Hendrix changes are now in place to send feedback of different types to different places. So, Dave: please can you create the following groups and associated lists?

mozilla.announce.prerelease

mozilla.feedback.firefox
mozilla.feedback.thunderbird
mozilla.feedback.firefox.prerelease
mozilla.feedback.thunderbird.prerelease

Thanks,

Gerv
Assignee: gerv → justdave
Summary: Need two USENET groups and Mailman mailing lists setup → Create new mozilla.feedback.* newsgroups
There are quite a few folks testing the trunk. Instead of having that group lumped into the prerelease, couldn't we have a separate newsgroup for that?  Also Tomcat suggested that users might not understand what prerelease encompasses.
(In reply to comment #15)
> There are quite a few folks testing the trunk. Instead of having that group
> lumped into the prerelease, couldn't we have a separate newsgroup for that? 
> Also Tomcat suggested that users might not understand what prerelease
> encompasses.
> 
I don't think Trunk feedback is going to go to the prerelease channels (it shouldn't).  The prerelease group should only be used for manual feedback for alphas, betas, and rc builds ("beta" releases)... all "browser" hendrix feedback should either go to mozilla.feedback, mozilla.feedback.firefox, or mozilla.feedback.hendrix... what do you think Gerv?
I expect that all feedback will, by default, go into (e.g. for Firefox) mozilla.feedback.firefox. If people want to subdivide it for a purpose, as Basil has requested here, we can specify more closely by creating a subgroup like .prerelease. (Of course, you can never be certain that you will capture all the feedback in the right place.)

If people feel we need to further divide trunk out from the other feedback, we can. Although, to be honest, I'm fairly surprised people care - Hendrix was originally designed as a bit bucket. :-)

Gerv
I think it makes sense to divide the hendrix postings into product-specific newsgroups. Can there still be a "unified" newsgroup for all of them. There are reasons to both want a single point to locate all hendriz postings and to make sure none of the postings fall through the cracks.

It does not cost anything to have postings cross-posted to something like mozilla.feedback.all, does it?
Ray: what's the use case? We can split on the X-Hendrix-Product headers or recombine for analysis by just concatenating the files together.

Gerv
What is the reason to not? Cross-posting costs almost nothing.

Sometimes people will want to look at the feedback divided into product buckets, and sometimes not. Why make one of these harder? Why not be flexible? Especially when it costs nothing.

As for a specific use case, I will only say that I am pulling hendrix reports into a database for analysis. It is nothing I expect anyone else to care about right now, but it is just a thing I am doing. Working with WebObjects for as long as I have, I build databases and apps. It is just a habit.
(In reply to comment #20)
> What is the reason to not? Cross-posting costs almost nothing.

Duplication of posts can be a hindrance to people. Sure, you can say "don't subscribe to that newsgroup", but what benefit does it have to have them all together? Just because there's no reason *not* to do something, doesn't mean there *is* a reason *to* do it. And you haven't given a good one yet.

> Sometimes people will want to look at the feedback divided into product
> buckets, and sometimes not. Why make one of these harder? Why not be flexible?
> Especially when it costs nothing.

Why would you not want to? For the practical purposes of most applications supported by hendrix (Firefox, Thunderbird, etc), there's almost never a time when you won't want to and those times (such as, for analysis) can be controlled on your end and don't need to be controlled on the newsgroup end. For some apps, we've even made it so they don't go to a newsgroup at all (see Camino) and instead go to the appropriate place where they read feedback. A bucket of all information with no form of sorting or classification is almost never useful.

> As for a specific use case, I will only say that I am pulling hendrix reports
> into a database for analysis. It is nothing I expect anyone else to care about
> right now, but it is just a thing I am doing. 

Wouldn't it be just as easy to build 'pulling from multiple sources' into your app? And wouldn't that be the most beneficial in the end anyway? There are other sources of user feedback. If you want to get them all, they'll never all go into hendrix.
The goal of this change was to separate out feedback for various products and our "beta" releases.. and make it easier for the community to track feedback in those individual channels (reduce noise somewhat).

I'm not totally against cross-posting, but don't really see the need for it.  As Sam mentioned, compiling all the channels into one dataset can be done with scripts or the app.  Making the app more robust to handle multiple channels just makes more sense to me.

Sure some folks might want to see all the feedback in one place, but more people rather only see feedback for the product they are concerned about.  We could have it both ways, but I think cross-posting will just confuse more folks than help... especially since we're making a push to get more people looking at feedback.

So... how about we stick to the original plan... and if enough folks feel the need to cross-post everything into mozilla.feedback, we can do that later.  Sound good?
I think flexibility is its own goal. Unless we know everything we will want to do in the future, flexibility is a good thing. If people want the groups to only exist divided, that is fine. I can work with it.
Can we get this completed please? We'd like it to be live for the Firefox Alpha 4 release that's coming up within the next couple of days.
I emailed justdave directly a few days ago and he said he was going to do this soon.  Hopefully he can get this done by the end of this week so we can start collecting feedback for alpha4 next week.

Dave:  What's the ETA for this?  Can you have this done by tomorrow?
Severity: minor → critical
The mailing lists have been created, admin passwords have been mailed to Basil.  Newgroup requests have been sent to both Giganews and Google.
Status: NEW → ASSIGNED
Whiteboard: waiting on Giganews/Google
Will these show up on news.mozilla.org also? I would have expected to see them there earlier than later. They do not seem to be there yet.
(In reply to comment #27)
> Will these show up on news.mozilla.org also? I would have expected to see them
> there earlier than later. They do not seem to be there yet.

$ host news.mozilla.org
news.mozilla.org is an alias for news.mozilla.giganews.com.

Giganews runs news.mozilla.org, not us. We just run the mailing list side of it (lists.mozilla.org).
These newsgroups are showing up on news.mozilla.org now.  They are not yet on Google.  I have unhidden the mailman mailing lists.
Whiteboard: waiting on Giganews/Google → waiting on Google
These are now live on Google Groups.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Whiteboard: waiting on Google
You need to log in before you can comment on or make changes to this bug.