Last modified: 2013-12-18 17:05:27 UTC
Right now we've a BetaFeatures component – https://bugzilla.wikimedia.org/buglist.cgi?component=BetaFeatures&product=MediaWiki%20extensions&list_id=259910 – but no single place to put bug reports about features that use BetaFeatures. Some of these have components of their own (e.g. MediaViewer) or even products (e.g. VisualEditor), but others don't (and probably won't). Right now, there's nowhere to raise a bug about e.g. Typography refresh that won't muddy up the bugs about BetaFeatures itself, as opposed to things that use it. Suggestions on better naming welcome. :-)
All BetaFeatures are currently parts of some extension, so the bugs should probably be filed in the extensions, no?
(In reply to comment #0) > Right now, there's nowhere to raise a bug about e.g. Typography refresh that > won't muddy up the bugs about BetaFeatures itself, as opposed to things that > use it. Those should be filed against VectorBeta. Though, supposedly those styles are actually in core, so the bugs should be filed in core? (In reply to comment #1) > All BetaFeatures are currently parts of some extension, so the bugs should > probably be filed in the extensions, no? I agree.
Yeah, agreed with MatmaRex, this seems mighty silly. If anything, it wouldn't go under the Extensions product, because you're talking about something that *isn't* an extension, it's either only part of one or some sort of weird core betafeature.
So… we should just throw them in "General" and hope they get worked on? Lovely. :-(
(In reply to comment #1) > All BetaFeatures are currently parts of some extension, so the bugs should > probably be filed in the extensions, no? Yes. If extensions are missing I should create them (bug 58616, bug 58617, etc).
Please reconsider or at least rethink the problem as there is a real problem here in my opinion. From my perspective: 1) People should not be expected to know from which extension beta features come from so in the current scenario various bugs will be filed incorrectly. 2) Beta features don't always plan to graduate to stable so are lower priority then the extensions that house them. For example - nearby pages is part of MobileFrontend. The purpose of the experiment was to explore whether such a feature was useful in desktop. If it is, it will need MediaWiki UI and a massive rewrite before being pushed to desktop. Now I am seeing a flood of bugs filed under mobile from problems experienced in the Beta Features environment field. These tend to not be helpful as I'm aware the code has issues when run in desktop. I would like some way of keeping these bugs separate from what I see as real bugs. I am very close to wanting to kill this beta feature because of this noise as I feel the bugs are intruding on the mobile teams core work which would be a huge shame. Please dont make me do this...
The primary organization structure of Bugzilla is products and components which are mostly based on code repositories or code areas. (In reply to comment #6) > 1) People should not be expected to know from which extension beta features > come from so in the current scenario various bugs will be filed incorrectly. I'm happy to edit the BetaFeatures component description in Bugzilla to link to a wikipage that explains which beta feature is called how. https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-betafeatures has links to "Information" and "Discussion" so you're free to add a link to corresponding Bugzilla components on the Information page. Or using the Bugzilla parameter of the {{Extension}} template. > Now I am seeing a flood of bugs filed under mobile from problems experienced > in the Beta Features environment field. Example bugs welcome so I can investigate plus if there are patterns I should improve documentation.
If features could provide preferred bug links that would be more useful.. Personally I just want to use talk pages for both of my features. I ignore the VectorBeta component. With respect to typography it's just not stable enough to warrant bugzilla bugs.
