Community
Participate
Working Groups
From http://www.eclipse.org/mail/index.html: "Technical questions and discussions about using eclipse and eclipse-based tools, and developing plug-in tools should be posted to the newsgroups. Mailing lists at eclipse.org are intended for use by developers actually working on or otherwise contributing to day-to-day development. The development mailing lists are the way design and implementation issues are discussed and decisions voted on by the committers." It follows that not many people need the mailing lists compared to all the users who come to the eclipse.org web site. Therefore there is no need for a 'mailing list' link in the main navigation bar on the left hand side. Furthermore, committers have to deal with people who ask user questions on the development mailing lists several times a week. The typical reply is 'please ask such questions on the newsgroups'. When asked, the users generally say they just found the mailing list from the navigation bar. They don't notice the warning at the top of the mailing list page. Removing it from the navigation bar would help people find the right forum in the beginning. I can imagine it's somewhat off-putting to be told you're not asking in the right place too. Also in the cases where developers do answer a usage question in the mailing list, i.e., the wrong forum, that is one answer that will not be found in a search of the user forums, leading to duplicate questions later on for people using the user forums. Some people have asked for mailing list versions of the user newsgroups. That's not covered by this request. Obviously if that happened, then a mailing list link would be appropriate but it would go to the user mailing list page not the development mailing list page. The development mailing list page should continue to exist, just not be linked so prominently as to mislead users. It is already linked from eclipse.org pages dedicated to committer/developers.
This is a bad idea. You should not make it harder for people to find out about the mailing list. I understand the problem. In fact, I posted such a request for information. There should be a FAQ for the list that clearly explains the situation and new subscribers to the list should be sent a pointer. I looked for such information before I posted and could not find it. This would be a better solution in almost every way.
Disagree with Ralph. There is already a section at the top of the mailing list homepage which describes all this. There is obviously a large segment of the community which doesn't bother to read it (or just blatantly ignores it), so I don't think emailing them a copy will help all that much. Anyone who actually cares about participating in or tracking the development of one of the hosted projects will surely investigate enough to find the lists. If we're really paranoid about parties who are interested for the right reasons not being able to find the page, then why not have a "Developer Resources" section in the main navigation bar, and put the lists homepage somewhere under that?
Another alternative to removing the direct mailing list navigation (which seems to have some opposition) would be to split the current disclamer and the list of mailing lists in to two pages - the first being the disclamer (possibly with more emphasis) along with a click through to the mailing lists. This would make it a lot more difficult for users to scroll directly to the meat of the page. Generally speaking, the current disclaimer simply does not have enough emphasis to clarify it is not for end user questions and discussion. I think the overall goal should be to give users more visual cues to read the disclaimer.
The problem is new users. We want to encourage them to use Eclipse, but they come to eclipse.org, they see "mailing lists" listed prominently in the navigation bar, they click on it, they click on one of the shortcuts or the first list link they see, and they ask a question. They're thinking, this is the way it works with every other project so why not with Eclipse? Then they get shot down with a polite, or not so polite, request to take their questions elsewhere thank you very much. Not a good first time experience with the community. I've included some excerpts below. It's really maddening, not just for those new users but for everybody reading the list (like me). Something needs to be done about this, please. If you don't like my suggestion then come up with something better. "I am a newbie to Eclipse - writing a new plug-in - not sure if this is the correct forum for UI events question -" "I 'm a newbie to eclipse tools.I dont know whether I'm using the right forum to put across this question." "I am new on using SWT," "Please use the newsgroup for such questions." "Note that future usage questions should be asked on the newsgroup, not on this list. " "Please use the newsgroup for questions. " "i don't think this is the place for those types of questions. " "how do you actually do it?" "the mailing list is for the eclipse developers only." "Hi, I don't if this is the list to post my question, but I haven't found a eclipse-user list. If it's not the place to post, please tell me which wolud be." "The eclipse.webtools newsgroup is for user-level questions such as this one." "none of the lomboz or the web and ejb projects appear in the file->new- >project menu" "Please DON'T reply to this list." "I'm sorry for that,but I don't know who can help me..."
Although I 'fight' generally for the 'rights' of the users, it is _very_ important to shield developers from the (uncontrolled) newcomer requests. - as a first step: remove link from main page - then: distinct clearly between developer/committer and user resources - ensure that at least one project member serves newsgroup requests with patience (if one becomes tired from coding, this is a nice recovery). - ensure that eclipse.org has the relevant resources, thus users are assisted in helping each other (categorized newsgroups, dedicated newcomer newsgroup, etc.). I would even suggest to make the groups read-only, to ensure the efficiency of the teams. Users can still monitor the mailinglist, and they can publicize and discuss a mailinglist-article to the newsgroup. Thus the "prime-directive transparency" is kept.
correction: "I would even suggest to make the groups read-only" => "I would even suggest to make the mailinglists read-only"
Some alternatives to consider: 1. If there's a way to make the mailing lists read-only to all but committers (as ilias suggested), it would also solve the problem of new users putting the questions on the dev lists and being told to go somewhere else. However this is a bit too draconian for my tastes. 2. Another approach (I don't recommend this) would be to give up, surrender the dev lists to user questions, maybe even make them mirror the newsgroups (though there's not a 1-1 mapping). Create some other mailing lists for developers and only mention them down in the developers web pages. 3. Another approach is to create a new set of mailing lists that do map 1-1 with the newsgroups and have them be a mirror of each other. People could use whichever format is more convenient. The mailing list link on the main eclipse.org navbar would be changed to these lists instead of the dev lists. I've suggested using gmane for this before (which would require zero resources on eclipse.org's part) but there were some (overblown imho) concerns about spam protection. I'm cc'ing Jim on this to see what he thinks the best solution is. We keep going round and round on this and I'd just like to see something done even if it's not what I suggested.
I definitely do NOT want to see the lists closed so that only committers can post. New participants to projects would then have a very hard time getting further involved. As an example, on CDT, there are many participants (myself included) that contribute to the project, but aren't official committers yet. Closing the lists would make it harder for us to participate in discussions, submit patches, etc.
comment 8 - i understand the problematic, but the thinking-flow of the developers should have priority. - the developement-mailinglist write access should not be bounded to committer status - if one contributes a few things (like bug reports, some active participation on newsgroup) or simply a friedly request with a statement "i have understood that this here is only about developement", he should get immediately the write access. [all this is of course independent of the removal of the main link, which is obviously missplaced]
Re: #9... We *are* developers on CDT, we just do not have committer status. The set of developers is a superset of the committers. The difference between the two is that code is filtered through the committers as they are the only ones with write priveleges to the CVS repository. If you make the mailing lists committers only, you will cut out developers, period, and since the lists are for developers, this would be exactly what you don't want.
Comment 10: ok, i've understood the vocabulary. - committers get write access to mailinglists. - developers get write access to mailinglists. further write access to mailinglists is given to _anyone_ who swears "I have understood that this list is about developement issues only. Usage and installation issues belong to the user newsgroups". This process creates a weak(!!!) entry barrier, which should protect the dev-lists from the most of the initial off-toppic messages.
Well, there are two ways. You can try to knock everybody out or your can create an eclipse-users list. However, I don't believe that adding more warnings and posting guidelines will solve this issue. It's like working with Windows: just click every "Yes" button till you get what you want. +1 for moving the link from the left bar to the main developer's site. +1 for creating user mailinglists that maps to the newsgroups +1 for putting the link to the user lists into the left bar
The mismatch between newsgroups and mailing lists is a problem because regardless of "normal" procedure some developers and teams will gravitate more towards their mailer or their news reader - typically for no better reason than one or other client has a better search capability. When I needed early access to the emerging 3.0 capabilities, I tracked all the milestone releases and several nightly builds (whenever specific items of importance to me were included) - knowing when and what to get was made more difficult because of the differnt places where information might have ended up. There was always a chance that information could slip through the gap - lurking somewhere that I hadn't effectively searched. So: +1 for having a news-mail mirror, and therefore +1 for giving some groups restricted write access, to keep the chatter down. -1 for hiding the groups since it would not be necessary if write access were restricted.
in eclipse.org, "newsgroups" implies "users", "mailinglist" implies "developers". This is wrong. It leads to the missleading use of the terms "Newsgroups" and "Mailinglists" in the main navigation. The correct links from the main page would be : - user forums [or something similar] - developer forums [or something similar] => rename links - provide different access methods/protocolls: - User Newsgroups (already gated to HtmlGroupd) should be gated to mailinglists - Developer Mailinglists should be gated to NewsGroups and HtmlGroups - use of internal eclipse.org resources - use of at least one additional external resource for archival purposes Thus users / developers can use their prefered access method to read/write to forums. +1 rename links +1 weak write protection to developer recources, as described alternatively: remove mailinglist link (topic of this bug) +1 future: forum = nntp, http, mail, ... {possibly further access methods}
From the users I've talked to, there are a few who don't want to use newsgroups for one reason or another but the vast majority simply don't know any better. They just went to www.eclipse.org, clicked on something that looked like a good place to ask questions ("mailing lists") and went from there. The whole mailing-list-vs-newsgroup issue is secondary to directing the users to the right place from the web site. And if I'm right, this is very easy to solve by removing the highly visible "mailing list" link from its prominent position. I like ilias' idea about renaming the link(s). The term "forum" or "user forum" is clear enough, however it's not clear who would count themselves as a "developer". If I'm using Eclipse to develop a Java program am I a developer? If I'm writing an Eclipse plug-in am I a developer? Both of these people, we want to use the user forums. In fact, almost everybody, say 99%, of people who visit www.eclipse.org should be using the user forums exclusively. Why is it such a leap to remove links from main navigation that such a small fraction of visitors will need? If nothing else isn't that just basic web site design 101? People who need it can find it under projects > development resources. I don't like the idea of restricting write access to the -dev lists. Why? I'm sure any such system will prove too hard to maintain, and it will generate resentment about exclusive clubs and whatnot. Besides there have been plenty of times where committers solicited community input on the -dev lists. This has been useful and there's no reason to supress that. Let's not go there please. Meanwhile I suggest anybody who feels it's needed to open a new bugzilla request for mailing list mirrors so that these two different issues don't get intermingled any more. I said in the initial request that this is not covered by my request. Frankly I'm getting tired of talking about this. If somebody would give me commit rights to the eclipse web site I could have this cleared up in 5 minutes. :)
The "Mailinglist" link is removed from: main search bugs PROBLEM: after selecting any of the other main menue entries (e.g. "about us", "projects", ...), the "Mailinglist" link is back again. Please correct! - This Bug (like all others affecting eclipse.org infrastructure) should be moved to the dedicated issue tracking category, after it is created : https://bugs.eclipse.org/bugs/show_bug.cgi?id=54024 [closed bugs, too - if moving closed bugs is possible] This way the domain knowledge captured (e.g. within comments) is available within the correct category (Bugzilla Product "eclipse.org" [example naming]). Additionally: the platform bug statistics are currently incorrect due to the unprocessed/processed infrastructure issues.
Forwarded to eclipse.org content manager.
Thanks for the feedback. Our intent was to make incremental progress towards eliminating unintentional mailing list traffic. We made a simple change that would catch some easy cases. We successfully made that change, but now you are observing there are additional things to do. I agree that "about us" should not point you to the mailing lists. We intended for developers who were digging into the project content to get the list, so the "projects" link makes sense, given our initial intent. We'll add this to the list of improvements needed for the website. We aren't planning on doing much more right now.
Many pages at eclipse.org still have "mailing lists" in the navigation bar. For example, click on "community" from the front page and you will see it appear right after "newsgroups". The dev mailing lists are still seeing a large amount of user questions. Reopening under new component for web site problems. Hmmm... I was told that Community/Website was the right place but I don't see Website in the dropdown list so I'll try Community/Doc.
Interesting, when I submitted that last change, bugzilla said that Community/Doc was invalid and the list of valid component values it provided included Website. It definitely wasn't in the list of valid component values before. Must be a problem in how bugzilla populates that Component dropdown. I'm currently using Firefox 1.0. on WinXP.
Dang it, changing the product field deleted all the votes on this bugzilla entry, and you can't vote on things in the Community project for some reason. I believe there were 15 votes active at the time. Sorry about that. The assigned-to field probably needs to be changed but I'm not going to mess with it. This is my last update for a while, promise. :)
Here's an example message that showed up recently in the developer mailing list that should have gone to the newsgroup forum. > -----Original Message----- > From: eclipse-dev-admin@eclipse.org > [mailto:eclipse-dev-admin@eclipse.org] On Behalf Of Usha > Sent: Thursday, December 09, 2004 4:44 AM > To: eclipse-dev@eclipse.org > Subject: [eclipse-dev] Problem installing lomboz intergrating > Jboss within eclipse......Plz help > > Hi list, > > I am trying to intergrate JBoss (version 3.2.1) within > eclipse IDE (version > 2.1).I have installed lomboz version -301 and extracted the module > "com.objectlearn.jdt.j2ee_3.0.1" to my eclipse plugin > directory, and i have > created the server config file jboss321all.server. Now I > expected to get > the "Lomboz Action" item in my current perspective clicking Window > > Customize perspective> Others. But it fails !! > > Can anyone tell me what i am missing with. Plz help !! > > TIA >
Here's another example message that showed up recently in the developer mailing list that should have gone to the newsgroup forum. > -----Original Message----- > From: platform-swt-dev-admin@eclipse.org > [mailto:platform-swt-dev-admin@eclipse.org] On Behalf Of clipse zeng > Sent: Tuesday, December 07, 2004 1:38 PM > To: platform-swt-dev@eclipse.org > Subject: [platform-swt-dev] I'm fresh in using swt > > Hello all, > I'm fresh in using swt.Authough I have seen many > articles and pdfs, I > still have some questions. > When an widget'action happend, it is quite usual to get > some inputs > from the UI ,and then ouput the results on the UI.How can I operate an > widget to get and ouput the information in an action procedure.For > example, a button 'ActionButton' is selected, then the coresponding > selectionAction will excecute. Within the action procedure, I want to > get the string from the Text 'TextB' and display the string in the > wigdet Label 'LabelC'. How? Please give me some examples. > I want to use > org.eclipse.jface.window.ApplicationWindow to create > my own appliction. Can ApplicationWindow set many Composite?How to? > Thanks. > Best regards, > Zeng Zhiping
Here's another example message that showed up recently in the developer mailing list that should have gone to the newsgroup forum. > -----Original Message----- > From: platform-update-dev-admin@eclipse.org > [mailto:platform-update-dev-admin@eclipse.org] On Behalf Of > Hussein Hammoud > Sent: Friday, December 03, 2004 1:31 PM > To: platform-update-dev@eclipse.org > Subject: [platform-update-dev] <no subject> > > Hi, > > I have been working with eclipse for 2 Weeks (eclispe 3.0.1). > I am trying to add the Visual Editor Plugin (including GEF > and EMF) to the > eclipse platform. I downloaded GEF, EMF and Visual Editor > form "eclips.org/ve" , but could not > add these components to the platform. A ".eclipseextension > marker file" is expected in folder "eclipse". > An in folder "eclipse" there are only two folders, "plugins" > and "features" > > I am grateful for every help!! > > > Sincerely yours > Hammoud
This shows a typical response. Readers of the -dev list have to read the initial message, then somebody has to write a response, and all the readers have to read it. > -----Original Message----- > From: eclipse-dev-admin@eclipse.org > [mailto:eclipse-dev-admin@eclipse.org] On Behalf Of Daniel Megert > Sent: Friday, December 10, 2004 4:19 AM > To: eclipse-dev@eclipse.org > Subject: Re: [eclipse-dev] editor plugin custom open/save > > Please ask those kinds of questions in the newsgroups. This mailing list is > for those developing Eclipse. > Regarding your question: maybe your document provider's getDocument(Object) > is not correct. > > Dani > > From: Roberto MIlev <milev_r@yahoo.co.uk> > To: eclipse-dev@eclipse.org > Subject: [eclipse-dev] editor plugin custom open/save > > > I am developing a editor plug-in that extends TextEditor. I have a custom > XML format and I want just part of the content to be edited in the editor. > Upon save I want to merge the changes and save the file in the XML format. > > I tried overriding the createContent and doSave methods in the Provider > class but after I save the file I get the full XML content in the editor. > > What should I do? > > Thanks >
It's been pointed out that there are three or four mailing lists that are not for Eclipse project developers (i.e., don't end with -dev). Clearly if there are user mailing lists then they shouldn't be made harder to find by removing them from the navigation bar. This also means the blurb at the top of http://www.eclipse.org/mail/index.html needs to be updated. It currently says *all* mailing lists are for developers the way I read it. How about this instead: Somebody suggested replacing the mail and news pages with a page for 'user forums' and one for 'developer forums', which sounds good to me. - 'user forums' would have both the non -dev mailing lists and the newsgroups. It WOULD be on all the nav bars. - 'developer forums' would lists the -dev mailing lists and would be buried somewhere in the project developer web pages. It would NOT be on the nav bars. The exact terminology can be debated but if you have both mailing lists and newsgroups that general users are expected to read then it makes sense to me to list them on the same page, and for that page to not have anything they're not generally expected to read. Can we agree on this point: A quick purusal or search of the site should only turn up general user forums, in order to prevent people who don't know where to post their questions from posting in the dev forums. We want to make it easy for newcomers to find the right place and hard to find the wrong place.
Another option to steer users to the newsgroups would be to provide a link on the welcome page that explains how to obtain support from the eclipse community. For instance, after mozilla completes installing, you are redirected to this page http://www.mozilla.org/start/ which describes how to report bugs and reach out the mozilla community for support. Since they use irc for developer discussions, they include the "please don't bug mozilla developers on irc with support questions" statement :-). This allows new users to see the appropriate forum for support as soon as they have installed the product. Currently the eclipse community link is under welcome-> what's new-> eclipse community which just points to www.eclipse.org. It would be better if this link pointed to a page that provided an explanation of how to open bugs, ask for help etc. similar to the one at mozilla.
That might help some, but I think a lot of the confusion with these kinds of explainations, even if they're read, is that people consider themselves "Eclipse developers" if they are a) developing something with Eclipse (like a Java program), b) developing plug-ins for Eclipse, or c) developing rich client applications. However, questions about all these categories do not belong on the -dev lists; they belong on the user forums like eclipse.platform.* instead. Mozilla doesn't have this problem because Mozilla is a browser not a development environment.
See also bug 88250.
Adding Francois, he will be interested.
+1 for re-organizing the pages so the user newsgroups and mailing lists are obvious and the development lists are under development resources. (In reply to comment #26) > Can we agree on this point: A quick purusal or search of the site should only > turn up general user forums, in order to prevent people who don't know where to > post their questions from posting in the dev forums. We want to make it easy for > newcomers to find the right place and hard to find the wrong place. This sounds like a really good idea. A lot of users will jump to the first opportunity that they find, and (as has already been mentioned) many other open source projects have a -users mailing list for help. Users will go where they're most comfortable. Later, Paul
A few things have been done lately to encourage users to use newsgroups: - posts by mailing list non-members are automatically rejected with a rejection message as per bug 98713 (previous behaviour was to silently discard) - Mailing list moderation is now an option to committers as per bug 88250 (eclipse-dev is currently the only list moderated) I feel -dev list moderation is currently the best way to handle this, so Im closing the issue. Perhaps eclipse-dev members can comment on the functionality of the list before and after moderation? D.
> A few things have been done lately to encourage users to use newsgroups: Also, some of the user groups are now mirrored at eclipsezone.com which should make them more attractive for people who don't like or can't use nttp. See: http://www.eclipsezone.com/java/forums/t43578.html
*** Bug 189478 has been marked as a duplicate of this bug. ***
