I’m going to go with “less change control and fewer broken promises”. We roll this out to beta features, and that’s all that is ever going to happen with it - it will die a slow death there, because it’s unlikely we will ever roll it out to production. Not because it’s good, but because we need to maintain a solid process of change control management. That is: as few changes as possible.
In this case, this is a change that would be obviated in short order, and we’d have a crazy heavy political fight over it in the mean time.
(Note that I love the direction this goes in. I just am thinking strategically.)
On Jan 2, 2014, at 6:38 PM, Mark Holmquist mtraceur@member.fsf.org wrote:
On Thu, Jan 02, 2014 at 06:20:01PM -0800, Brandon Harris wrote:
I don't know how much effort we should spend trying to make talk pages easier to read when we've got Flow on the main burner.
The beauty of this is, it's a fast solution that we can push out and not need to do much work on it. The community is pretty good about responding to calls for feedback on BetaFeatures, and JS/CSS fixes for something this small will likely not take much engineering resources.
Also I'm not sure this would be *only* helpful on Talk pages, I think very dense pages could benefit from this too - stuff that's really heavy on detail and prose.
-- Mark Holmquist Software Engineer, Multimedia Wikimedia Foundation mtraceur@member.fsf.org https://wikimediafoundation.org/wiki/User:MHolmquist _______________________________________________ Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate