As a Web developer I want to turn off the alpha channel so that I don't have to maintain various features across different release channels.
For this task to be completed for every feature that was previously enabled in alpha we should ensure:
this is hard to gauge without a preview--but I agree that if we promote it should move to 'settings' and we can use some sample text for people to gauge impact.
I'm a bit confused now: The design decision was to move it somewhere, where the user can test the result before saving (or saving while testing). My first prototype was on Special:MobileSettings, btw. I would welcome some Design input before invest time into it :)
@Florian Sorry about the run-around. I'll create a new ticket about the font changer and ping design to comment on it. It just seems silly to me to take up valuable vertical space in the hamburger menu with a feature that will rarely be used, but that's just my opinion :)
The plan sounds good to me, but ultimately we should be aiming to have all the beta/alpha features (for starters) covered by feature flags.
That way we can enable/disable them in different wikis (for example we may want to have all of them enabled on beta labs, but not ship them to enwiki & friends for a while).
It'd be great if we could come up with how we are going to feature flag the code, and have a session were we feature flag any little feature, to show how to add the config, how to feature flag on the php, JS and LESS code.
Regarding the specific features, I'm a bit concerned about throwing away the wikidata infobox, since it has helped us show several times how we could have a better infobox with structured data. IMO I would feature-flaggit and leave it in beta, but just enabled on 'beta labs', so that we can show it when necessary but it is not anywhere else.
That said, if @Jdlrobson thinks it should die, I'm not going to oppose.
With a bit of work we could add these features to beta features and make it a healthy ecosystem a la gadgets. @Tnegrin does reading own beta features now?
@prateek is doing a font changed for desktop and @violetto did one during the hackathon.
@JKatzWMF
Cool this all sounds great!
I'm concerned about Report an Error. What do we hope to learn by moving to beta? Where do the reported errors go?
I thought after the problems with the article feedback tool we were wary of things like this.
yes I think we should be wary of this as well, but let's remember that ATF represented a bad solution to a real problem. That doesn't mean the problem should not be solved. Implemented. Unlike AFT, this is a very small treatment that goes into the talk page and we are measuring it in beta. The risk here is very, very low.
I would like to use EL it and see what happens (by tracking strings that are entered) for such a simplistic treatment. If, on this little treatment, we see a high noise:signal ratio, it indicates that getting feedback from users needs re-imaginging. However, if the noise:signal ratio is high, we can then figure out how to move forward.
Others have pointed out that it is confusing as currently implemented as well, I think improved messaging would go a long way here.
Is your concern about having it in beta, or about pushing it into production?
Going to be working on this through the sprint, one piece at a time to be safe about promotions and releases.
I'll be moving this through the columns on Reading-Web-Planning when we work on them.
Change 231703 had a related patch set uploaded (by Jdlrobson):
Goodbye yellow brick alpha
Change 231703 abandoned by Jdlrobson:
Goodbye yellow brick alpha
Reason:
I haven't got time to see this through to completion right now but someone should feel free to resurrect it and take it over! :)
Change 231703 restored by Bmansurov:
Goodbye yellow brick alpha
Reason:
Let me see if I can finish this up.
I've left a question on @Jdlrobson's / @bmansurov's patch:
If the user is currently opted in to the alpha, i.e. they're interested in experimental features, then should we really drop them down to stable? (see MobileContext#getMobileMode – I think). If it's necessary, then shifting the users over to beta might be as easy as delivering a script to the client that opts the user into beta and out of alpha.
What do y'all think?
That sounds good. Or we can just fall back to stable because alpha is unpredictable ;) That may also let the user know that alpha is gone.
@Florian correctly pointed out that neither alpha or beta are cached so we could do the migration all on the server.