Community
Participate
Working Groups
I just updated an old workspace to the weekly of Mylyn with WikiText and noticed that the bugzilla repository was automatically markup-enabled. Since bugzilla doesn't natively support markup as with other issue trackers, I think that users should have to enable this feature. I like the WikiText integration, but want to ensure that other Mylyn users know that they have enabled an enhanced feature that is not supported by the repository.
Shawn, this was discussed in a weekly Mylyn meeting and the general consensus was that it's relatively harmless to have WikiText enabled for Bugzilla repositories by default. The reasoning discussed included: * the text editor still shows the source as typed * the text editor in most respects behaves like a regular plain-text editor ** notable exceptions include content assist, help content and text presentation * the comment viewer generally only alters the appearance of commonly used markup for lists * more advanced markup constructs are unlikely to appear in normal text I'm interested to hear from you what it is specifically that you're concerned about.
From the Mylyn conference call: * generally WikiText adds value to the Mylyn editor even for repositories that do not directly support markup * it makes sense to have a default markup setting for such repositories if we can converge (agree) on a specific markup language to use * if we're to have a default, it must be for 3.1 otherwise it will be too late. Having it for 3.1 will enable us to remove it for Galileo if need be. * MediaWiki and Textile have been suggested as defaults ** MediaWiki has the advantage for Eclipse.org users that they're likely familiar with Eclipsepedia *** bug 262973 must be implemented in order to use MediaWiki ** Textile has the advantage that *** it's compact, uses universally understood markup for bold and itallics, looks good in the web interface *** it's already optimized for use with Bugzilla *** Confluence/JIRA users will naturally know it since Confluence syntax is almost identical, Apache and many other open source projects use JIRA (and Confluence)
David, thanks for the update from the call, this does make sense. The thing that I am most worried about is that users will think that the bugzilla connector is broken if the rendering isn't what they see in the web ui (or close to it). Most of the time, everything works and can even look better, but if the user doesn't know that they are using a special rendering, they may miss something or see it different than it was intended. Another thing that could be a problem is that if the user doesn't specifically enable the markup, they won't know what "language" the editor supports and therefore may not be able fully utilize it, especially since it doesn't look much different when creating a comment. Based on the outcome of the call, I think that this bug can be closed. I will file a new bug for some oddities in the rendering that could confuse users.
Shawn, thanks for your comment. I'd like to leave this one open until the issue has been put to bed. Currently the team is trying out the task editor with the default WikiText setting until next week so that they can provide feedback on the default markup language setting. At next week's call we plan to discuss this issue again.
From today's call: * agreement that a default Bugzilla setting would be a good thing ** attempt to minimize false-positives ** seek more feedback from the community at large, including Eclipse committers and other Mylyn users *** WikiMedia markup language has no good solution for preformatted blocks * update Editor UI to make it easier to turn off, refresh editors ** Render As menu on comments, new comment and description, as well as pop-up menu *** changes to affect repository settings and all open editors ** View Source action to stay
Can we close this bug or are there still concerns that WikiText is enabled for Bugzilla repositories by default?
I think that this can be closed. I am happy with it.
Marking resolved as per comment 7.
