Community
Participate
Working Groups
Recent component rearrangements look quite strange to me. Someone should clearly specify and document criteria when components are moved components between sandbox and non-sandbox.
I should have said "project team" instead of "someone"
Yes, we should have a clear definition for this. My working definition is: "is the component of a high enough quality, simplicity and level of support to be distributed as part of the default Eclipse download?". Features on our main site will be distributed with EPP, which is set to replace the default download come June 29th. This means that the component needs a component owner and enough feedback for us to feel confident that it is solid and simple enough to use. This is *not* to say that we should not promote the extras, some of which are very valuable to the community. It's also note to say that we shouldn't re-arrange the extras. The current state of things is: * UI Usage Monitoring: no component owner, not enough feedback (<20 bugs reported) * JIRA: no component owner, known usability issues, potential for it to move out of eclipse.org * Web Connector: very advanced UI, not enough feedback (<20 bugs reported) * Sandbox: not supported
One more thing: the above is my current best assessment of the current situation. If anyone has an argument for why any feature should move from the Extras site and into the Standard site please post and we can discuss. Also, note that EPP is currently consuming the entire Standard site except for Trac: bug 187154 and with PDE missing from most configurations. Since Trac is supported and we could consider pushing EPP to use it. Or we could do the reverse and only leave the reference implementation (Bugzilla) to be on the Standard site, and put Trac on the Extras site, but with no "(Incubation)" tag.
Is there any stats around how many deployments of each issue tracker has? My subjective estimate is that each of Trac, JIRA and issue trackers that could be handled by the web connector are few times more popular comparing to Bugzilla. So, Bugzilla, included by default will be not much an use for majority of non-Eclipse committers.
The download rankings have been steadily the following ever since Trac came out: Bugzilla, Trac, JIRA. I'm missing a few released and should do a tally for 2.0M3. So the current split reflects that, but the more important issue is overall quality and support/ownership. My subjective opinion is that the web connector is not used much since there have been relatively few bug reports and questions. However, as before I perceive it as important for adoption. Note that the current packaging is not final, so all please post any other thoughts on criteria, etc.
Mik, my point is that you can't measure popularity of the issue tracking system based on connector downloads. So, my subjective estimate were based on the number of deployed issue trackers, not connectors. BTW it was your own argument for moving sandbox stuff into a separate update site. So, there is a great chance that web and jira connectors downloads will go down, just because they aren't on the main update site. A more representative experiment would be to move Bugzilla connector into its own update site...
Could you clarify what are you suggesting as the update site split and the criteria for choosing?
(In reply to comment #6) > BTW it was your own argument for moving sandbox stuff into a separate update > site. So, there is a great chance that web and jira connectors downloads will go > down, just because they aren't on the main update site. That is the whole point of not having them on the main update site. It lowers (quality) expectations if JIRA is clearly marked as "Incubation" and will drive less experienced users away lowering the overall support overhead.
(In reply to comment #7) > Could you clarify what are you suggesting as the update site split and the > criteria for choosing? I don't see point to suggest anything, since you clearly have your own ideas on the subject of this issue. So, please write them down somewhere.
Eugene: My current ideas are on comment#2 and I am totally open to feedback about those ideas and refining or changing the criteria. Even if you just write out how you would split the sites that would be useful. Fyi, check out this post: http://litrik.blogspot.com/2007/06/where-is-mylyns-generic-web-repository.html No matter how pronounced we make the update site we will always cause some confusion with any change of this form. This is a key reason why I want to make sure that we include less, not more, on the standard site. Once we go from tens of thousands to hundreds of thousands of monthly downloads it will be extremely difficult to remove anything from the site. In contrast graduating something from the extras site to the standard site will be straightforward.
(In reply to comment #10) > No matter how pronounced we make the update site we will always cause some > confusion with any change of this form. This is a key reason why I want to > make sure that we include less, not more, on the standard site. Once we go > from tens of thousands to hundreds of thousands of monthly downloads it will be > extremely difficult to remove anything from the site. In contrast graduating > something from the extras site to the standard site will be straightforward. Moving stuff around is fine (as long as *you* declare well defined criteria, that won't have subjective measurements like "high enough quality"). I could have missed something, but I was under the impression that web repository connector been promoted out of the sandbox before 1.0 release.
(In reply to comment #11) > Moving stuff around is fine (as long as *you* declare well defined criteria, > that won't have subjective measurements like "high enough quality"). I don't know of any objective criteria that we have reliable data for. We have download numbers and open/fixed bug counts and I checked all of those. That's why I'm curious to hear of others' of alternative ideas or splits, because in the end this will have to be a carefully made subjective decision. Or we could consider a vote if we do not have consensus. > I could have missed something, but I was under the impression that web > repository connector been promoted out of the sandbox before 1.0 release. Yes, it was. But the 2.0 release is another similar event of a considerably greater magnitude than 1.0. For 1.0 we removed a bunch of stuff like Active Search and Active Hierarchy since the UIs were too complex (even though I really liked those tools). Our tool is only as simple as the most complex part of its UI, and only as high quality as its lowest quality component. In all of this I think that the web repository connector is the hardest decision and one that we should continue to ponder since it is not too late. It is extremely advanced. However, if you don't use it, it does not get in your way. The problem I've been noticing with it is that people download the tool, only have access via the web repository connector, and then dismiss the tool as being too buggy or too complex because they can't connect. My model of it being simple enough is that it only requires the user to enter a URL and possibly credentials (as per pervious discussion on bugs about this). The URL provides a template that gets downloaded and that is maintained by the project or site. What are others' thoughts/experiences on its inclusion in the standard site?
(In reply to comment #12) > Yes, it was. But the 2.0 release is another similar event of a considerably > greater magnitude than 1.0. For 1.0 we removed a bunch of stuff like Active > Search and Active Hierarchy since the UIs were too complex (even though I > really liked those tools). Our tool is only as simple as the most complex part > of its UI, and only as high quality as its lowest quality component. I am ok with lowest quality, as long as it discussed within team. > The problem I've been noticing with it is that people download the > tool, only have access via the web repository connector, and then dismiss the > tool as being too buggy or too complex because they can't connect. I wonder where did you get this kind of data? Namely, how do you know no one is using some components or what components considered buggy? I have no insight information on that and it would be good if you could actually share your sources. To give you more specific example, I saw several bug reports within past couple months when reporters literally said that Bugzilla connector don't work. Does it a sign of "not high enough" quality?
(In reply to comment #13) > I am ok with lowest quality, as long as it discussed within team. I don't understand what you mean. Do you mean you are OK with putting our putting out low quality, or that we need to have a better definition of a quality bar (agreed), or something else? > I wonder where did you get this kind of data? Namely, how do you know no one is > using some components or what components considered buggy? I have no insight > information on that and it would be good if you could actually share your > sources. To give you more specific example, I saw several bug reports within > past couple months when reporters literally said that Bugzilla connector don't > work. Does it a sign of "not high enough" quality? Regarding data, it is only hearsay from conferences with users telling me they tried it but didn't get far. Also, there there have been <20 bug reports, since bug reports mean are always an indication of usage and lack of them is a data point. But this is not to say that the web connector does not play a VERY important role for adoption. It does. Just that my current idea is that it will serve adoption best by being on the extras site. Again, I'm not completely sure, but have outlined all of my reasoning, and again, I would like to know your and others' reasoning and data points on this. Connectivity problems will always be a challenge for us, and what matters is what proportions of users can get up-and-running quickly. We are about to go from a community that's dominated by early adopters (have patience for UIs and configuration), to one that's totally dominated by regular users. My bar for early adopters in terms of configuration was that regexps could not show up in the UI by default (those are for super advanced users). For regular users I think a good bar is that the repository does not require manual configuration beyond entering straightforward project/authentication attributes or URLs.
(In reply to comment #14) > I don't understand what you mean. I think you do. > Do you mean you are OK with putting our putting out low quality, or that > we need to have a better definition of a quality bar (agreed), or > something else? My interpretation of your previous comment is that you moved all low quality stuff outside of the main update site (which is most probably the only update site that may users will use, especially those who will came from Europa) and you've done on your own hunch out of blue, but maybe I just missed the whole discussion about that. At least it would have been polite to check with so-called "component owner"... > Regarding data, it is only hearsay from conferences with users telling me > they tried it but didn't get far. Cool! I hope you at least suggested them to fill the bug reports, because I haven't heard anything like that. > Also, there there have been <20 bug reports, since bug reports mean are > always an indication of usage and lack of them is a data point. or maybe it is an indication that everything is working as expected.
My $0,02: 1 - IMHO, splitting features in 2 update sites discourages the use/experimentation of "extra" features. I'm a lazy user and having to enter 1 update site is just enough. Have you considered to create a new category on main update site called something like "Extra connectors (incubating)"? 2 - I do agree with Eugene when he says download counts are not a realistic measure of use. Like I said on previous paragraph, I'm a lazy user, and when I search for new features on update manager, I just check Mylyn's root checkbox, downloading all features, although I don't use Jira/Trac. What is the main driver for this splitting?
Hi guys, for what its worth- I believe both of you are doing an excellent job by Mylar. Quality is easily on par or superior to other Eclipse projects, and user support is outstanding. My feeling is that Mik might be heading for even higher quality goals than the user community. Web connector is fine with me. Not submitting any bugs for it simply means that I'm happily using it. Did actually decide to do the same with UI reporting- only to not find it anymore. I believe moving already quite advanced components to extras repository is not helping adoption of these components- and confusing existing users.
I finally succeeded to get the Generic Web Connector but these were all the steps I had to go through: 1) I downloaded Eclipse 3.3 2) I got Mylyn 2.0.0v20070615 through the Europa update site 3) I couldn't find the web connector on the update site. I googled but only found URLs of Mylar update sites. 4) I wrote my blog post at http://litrik.blogspot.com/2007/06/where-is-mylyns-generic-web-repository.html 5) Comments on my post hinted to the "extras" update site (found on http://www.eclipse.org/mylyn/dl.php) 6) Added the extras update site 7) Installation of the web connector (2.0.0v20070621) failed because it needed a more recent version of Mylyn than the one available on the Europa site. 8) Added the main Mylyn update site and was able to upgrade Mylyn and install the web connector (2.0.0v20070621) I think most users would have given up after step 3. Now I have 3 update sites defined, all carrying Mylyn stuff. "Europa", "Mylyn" en "Mylyn extras". I agree with comment 15, comment 16 and comment 17: too many update sites. User will get confused. I suggest to have only one update site and indicate the difference in code quality (a good and noble idea) by using multiple categories on the update site, or by appending "Experimental" or "Beta" to the feature name. Just my 2 cents.
Thanks all for your feedback. I'm still processing it and expect to answer today. Please note my comment#52 on bug 187879 since it is closely related to this topic.
As a matter of interest, why is there any concept of different update sites, anyway? Wasn't Europa supposed to be a single release of projects? I'm all for allowing individual update sites for developer vs user access, but hiding things that are as well-documented on the Mylyn wiki (and were present in previous versions) just because you've not had good bug reports doesn't mean that it's neither well used nor important. Note also that the EPP packages (dash, dltk, buckminster) have had significantly less testing than Mylyn, yet also provide their content on the update site with low versions. The same could have been done for mylyn; make the web connector not part of the EPP package, but on the update site as a low-numbered feature. Frankly, I think that Eclipse Europa had too many update sites as it is, but for one project to have an extra update site that (almost) no-one knows about is a shame.
First of all, thanks to Litrik (comment #18) for the blog post that saved me a couple of steps. My experience was pretty much the same as his except: 1. All of my queries silently disappeared because they apparently relied on the missing Mylar web connector. Not a good failure mode. 2. I couldn't install anything until I untangled the BIRT examples which had gotten themselves installed in a state where they didn't think their installation prerequisites were satisfied, causing the update manager to refuse to consider any other requests. So much for the "high quality" of the bundled Europa components. Is the goal here quality as measured by some number that is monitored by a "suit" or quality as experienced by the end user, because the latter is woefully lacking with the current setup. I've been using Mylar for 6 months depending on the web connector, so the Europa Mylar release was completely non-functional for me. You can't get much lower quality than that. Other Europa components asked which optional components I'd like to install. Would it really be that hard to do the same for Mylar? How about installing the optional components update site automatically when the base component is installed so that users can find it easily rather than depending on some 3rd party's blog to find it? How about __[your solution here]__? "Processing feedback" is nice, but fixing the problem would probably make the users happier.
We should consider a service release that includes a fix for bug 195057 and would automatically add the extras update site to the update manager when installed. Installing the JIRA or web connector would still require extra steps but it would be considerably easier than it is now.
I have posted a draft of the criteria: http://wiki.eclipse.org/Mylyn_Contributor_Reference#Feature_Maturity Sorry for slowness on this, as expected we have been overloaded with user feedback since the EPP bundling. Please understand that we are doing our best to respond to feedback in priority order. Tom: I completely understand your frustration. Having anything disappear from your Task List in this way is unnaceptable, and the solution was non-obvious. Due to other fires around Europa/EPP I did not have enough time to put out a FAQ entry with expectations of all components and instead relied on users to either read the announcement or the download page. But since we no longer control the distribution channel of Mylyn (the packaging does) this did not make it to enough people. Excuses aside, I see two key issues: * You experienced an update problem. I saw some of those on the Data Tools project but they should have been resolved the Tuesday after Europa was released. If you see any other problems of this sort please file a critical bug against the offending component (and CC me if Mylyn might in any way be related to it). * You are suggesting that we add the Generic Web Connector to the update site, which will mean that it is effectively bundled with EPP. Note that there is nothing in Eclipse that has as remotely as sophisticated a UI as that connector, which requires users to understand and configure URL internals in the vast majority of cases. Please take a look at the criteria and let me know whether you think that the connector really should be available to all users downloading the default Eclipse packages. I just can't see how that will be a good idea until something equivalent to bug 195660 and I think that having those who are interested in it take a little bit of time to discover it is worth the cost. As Steffen points out we have resolved bug 195057 so this step will now be easier. Alex: what we put on our update site is effectively what gets distrubuted via EPP because of what happens when users try to update (i.e. get prompted for all features). However, we are still exploring figuring out how to make things work in the spirit that you outline (e.g. bug 194469) where users get EPP and only updates to what they got, but don't have to install a separate update site. The "sites to visit" will already add the site to the update manager. All: regarding the decision making process behind this, please note that there are no "suits". The week that we had to make this decision (i.e. the moment I realized how the EPP packaging could work, bug 187514 and what this would imply) I discussed the problem with the other two committers who were around about the best course of action (Eugene was away for a week, so I understand his being miffed at being away for a decision that involved the connector he owns). This had to be decided quickly and I still feel that it is very important that we moved all three of those components to the extras site, or we would be completely buried in problems that we cannot provide adequate support for since our user community has grown orders of magnitude and our committer/contributor community has remained the same size. But I do ask everyone who has disliked this decision to read those guidelines and comment so that we can make sure that we understand how to update them or improve on this.
For the record. I haven't been informed about these actions and been learning about them incrementally or from someone's bug reports. I don't recall if there was notification in the dev mailing list about the web connector (note about JIRA connector was also quite easy to miss) and this is the first time I hear that split had been discussed with other committers before hand.
This was discussed during our weekly meeting, then discussed further as part of several emergency EPP related decisions (see that bug) in personal/IM communication. A few hours later I put the change into what was the RC1 build and immediately sent a message to the newsgroup and dev list about the update site split (http://dev.eclipse.org/mhonarc/lists/mylyn-dev/msg00025.html ). Then we had 8 days for discussion and changes on this bug report or on the dev list. Naturally I wish it would have been longer since we might have learned that the "Sites to visit" trick could have addressed the discoverability problem.
(In reply to comment #25) Mik, you don't have to repeat this to me. Several weeks after, I already know all of that and the only reason of my previous comment is to inform you that it hasn't been properly communicated. That is all. No further actions required. Interestingly, that is the exact message I was referring to when said that it was easy to miss change for JIRA. It also didn't say anything about the web connector and didn't have url for the new update site.
I am monitoring devel and integrator mailing lists and somehow I missed that Generic Web Connector is not part of the Mylyn update any more and I only noticed that because of Alex B. post on Javalobby. I cannot speak for any other components distributed in Extras, but I think that Generic Web Connector should be part of the std. Mylyn distribution, only because it is the only connector to be used with biggest open source hosting site Sourceforge.net.
Lubos: I agree with your argument in the sense that the bigger the addressable impact of the connector the more desirable it is to have it available to as many users as possible. In this respect the Generic Web Connector is orders of magnitude more desirable than other connectors. However, it is not feasible to desirability alone as the reason for including a connector in the default Eclipse downloads. The first measure has to be the maturity as currently defined by the criteria at: http://wiki.eclipse.org/Mylyn_Contributor_Reference#Feature_Maturity In order to argue that the Generic Web Repository connector be included please provide an argument for how we should change those guidelines. Also please take a look at the 2nd screenshot of the following entry: http://www.jroller.com/eu/entry/web_connector_is_groovy While this clearly displays the connectors utility, there is no UI in Eclipse that is within an order of magnitude of the complexity of what you see there. The people who are comfortable working with this kind of UI (e.g. you, me, and everyone else CC'd on this bug report) should also be comfortable with the few extra clicks that it takes to install it in Mylyn 2.1M1. The majority of users will *not* be comfortable with this expert-oriented UI and need something like bug 195660 to use this kind of connector.
(In reply to comment #28) > Also please take a look at the 2nd screenshot of the following entry: > http://www.jroller.com/eu/entry/web_connector_is_groovy While this clearly > displays the connectors utility, there is no UI in Eclipse that is within an > order of magnitude of the complexity of what you see there. I don't think it is accurate. CVS repository configuration as nearly the same number of settings. Window / Preferences / Key panel is one of the most mysterious Eclipse UIs, after using Eclipse for over half of the decade I still don't completely understand how it works. You should also know that connector configuration is practically modeled after other well known Eclipse dialogs, namely "New Class" and "Find" dialogs. > The people who are comfortable working with this kind of UI > (e.g. you, me, and everyone else CC'd on this bug report) should also > be comfortable with the few extra clicks that it takes to install it in > Mylyn 2.1M1. You should know that any additional setup configuration is an extra step and it require additional research and knowledge of these required extra steps. My interpretation of comments on this report and questions in the mailing lists and news group is that not all users does have this knowledge and I am not really sure how situation would change any time soon. > The majority of users will *not* be comfortable with this > expert-oriented UI I wonder where such evaluation came from? Is there a user study or something?
(In reply to comment #29) > I wonder where such evaluation came from? Is there a user study or something? No user study, this is an opinion. If this opinion does not reflect that of others I am happy to do a vote but on a bug that is specific to the generic web connector so I created bug 197051. If voting for the simplicity of the generic web connector please provide a 1-2 sentence explanation and a listing of the steps that it took to set up your *first* query (this is the key aspect by which we can 'measure' new user experience). Since the criteria for inclusion have been written and there I am closing this bug, so all those interested in the Generic Web Connector specific discussion should add themselves to the CC on bug 197051. If anyone has suggested removals, additions, or any other kind of feedback on the guidelines please feel free to post them to this bug so that we can iterate on the guidelines and reopen if necessary. http://wiki.eclipse.org/Mylyn_Contributor_Reference#Feature_Maturity
We are now heading for the Europa Fall Update release so I would like to review the policy that was decided on here. The main cost of the change was the one-time confusion of the exclusion that resulted. For the Mylyn 2.1 release and Europa Fall Update this will be offset by the fact that we now automatically add the Extras site to the Feature Updates dialog. The current Extras components are the same as for 2.0 and the summary of each is: * UI Usage Monitoring: leave on Extras site, no significant change in component quality or feedback * JIRA: very good decision that we did not include with EPP due to all the major bugs that came in, many fixed, but still needs more work and a component owner, so leave on Extras site * Web Connector: leave on Extras, discussion is on bug 197051 * Sandbox: need to consider implications of leaving on Extras site now that we link it, created bug 204560 for discussion
