I suspect it isn't done because it isn't a very good way to modify a complex embedded base of software, Lila. Generally, when modifying a complex embedded base, one designs first, iterates implementation and internal testing, and then releases a relatively complete piece of functionality.
KWW
Lila Tretikov schreef op 2014/11/08 12:37:
We seem to really gravitate towards complexity on these things. How can we make them simple, addressing a very specific need. We can complicate later.
Here is a scenario (which we should start with, not architecture)
1. As an editor I'd like to flag a revision as reviewed/verified by me from the revision screen or list. 2. As an editor I want to see which revisions were verified/had second opinion by other editors.*So instead of a long spec that attempts to solve for a ton of cases, let's start thinking about solving simple, direct pain-points, iteratively.*
Can we do that?
L
On Fri, Nov 7, 2014 at 8:40 PM, Erik Moeller erik@wikimedia.org wrote:
On Wed, Nov 5, 2014 at 11:21 AM, Gabriel Wicke gwicke@wikimedia.org wrote:
What are the indexing requirements for this metadata? If fast access by specific properties is needed
Most typically, I'm guessing you'd do stuff on a per-revision basis to show quality indicators and such on page histories or article pages via opt-in gadgets. Querying the entire corpus for articles with certain characteristics would be valuable though, especially for applications like offline exports.
I just saw https://meta.wikimedia.org/wiki/Grants:IEG/Revision_scoring_as_a_service and wasn't even aware of that when I wrote the email -- there's definitely a lot of interest in a generic solution for this problem.
Erik
-- Erik Möller VP of Product & Strategy, Wikimedia Foundation
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l