Community
Participate
Working Groups
The goal of the Sandbox is to enable experimentation and usage feedback in order to evolve the existing (i.e. non-Sandbox) Mylyn UI. This means that we have two forces at odds: 1) Freedom of experimentation and a lower bar for patches. This makes it easier for contributors to add experimental components and removes the amount of UI iteration and unit testing required. This also has the effect of raising the amount of work needed to move components out of the Sandbox. 2) Quality of the components. A higher quality makes it easier for more users to gain enough benefit from the features to use them regularly, which promotes usage feedback. The line needs to fall somewhere between these two. In terms of quality, one idea is that no Sandbox component can violate a key Eclipse or Mylyn UI design guideline (e.g. respecting user preferences). In terms of experimentation, it could make sense to lower the bar some. However, we need to keep in mind that as of the Europa Fall Update a typical users Update click stream will cause the Sandbox components to be added. As such, if lowering the bar we have to consider moving the Sandbox components to a separate update site and out of the linked Extras site. If keeping the update site we have to raise the quality bar to meet expectations.
Based on the vote on our call, the policy is that Sanbox components will not need to meet the same UI requirements as the rest of the Mylyn UI. That said, I think that this is still strongly encouraged for Sanbox components since it will help enable usage feedback. In order to support this differentiation the Sandbox components will get their own update site, this site will support multiple features, and will be linked from: http://www.eclipse.org/mylyn/builds/
A remaining questions is whether we should point to the site from http://www.eclipse.org/mylyn/builds/ or whether to inline a link. Benefit of pointing to it is that we keep the page concise and that new users get to read about the Sandbox before attempting to install components from it. Cost is another link to click.
Congratulations, Mik! You finally managed to hide sandbox update site where nobody will find it. Project page / Downloads / Archives and other builds / Sandbox link to the wiki / there user would have to guess the update site location, which don't look like url - download.eclipse.org/tools/mylyn/update/weekly/experimental By the way, why it isn't called sandbox, but experimental?
Eugene: Opinion behind the sarcasm noted. What has actually happened is that the Sandbox update site is back to its original location before the 2.0 release. For the 2.0 release I put it into Extras because that was argued for, and for reasons discussed in the Description of the bug and on the call I think that this made it too prominent, which caused more harm in making people not trust the tool (e.g. trim widget could not be turned off) than it provided benefit (encouraging users to try out experimentation). The update site is called "experimental" in order to make it more meaningful to potential users. Both "sandbox" and "dev" were internal Mylyn conventions, whereas "experimental" and "weekly" are more meaningful to those not familiar with the project. When I do my iteration on the web site I plan on making the links to the Sandbox a bit more prominent for the following categories of users visiting the site: * Early adopters interested in experimental UI * Contributors interested in evolving the UI If others have suggestions on additional categories of users to consider please post.
