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 <[email protected]> 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
> [email protected]
> https://wikimediafoundation.org/wiki/User:MHolmquist
> _______________________________________________
> Design mailing list
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/design
---
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
_______________________________________________
Design mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/design
