Jeroen De Dauw schreef op 2014/11/09 0:29:
Hey,
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.
As far as I understand this is about adding a new service, not modifying
complex existing behaviour. Is that wrong?
Also, while I can't speak for Lila, it does seem to me she is suggesting to
go with a simple solution that tackles a specific need well, as opposed to
releasing something incomplete. The idea to build small dedicated units
rather than monoliths is not something new or controversial in the world of
software design. Even though it might be in certain insular communities.
Her comment included
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.
That's not a "service" by any definition I'm aware of, that's a user
interaction, one that seems to presume the existence of the Wikimedia base.
There's no doubt that there's a lot of leeway in terms of how much one
implements in each release of software, but one should always have a
reasonably clear image of the final target, know where the piece being
implemented now fits into the final result, and take steps to ensure
that each release is sufficiently complete to be useful. There have been
some successful products built using the "code first, design later"
method, but that doesn't mean it should be encouraged. Even SCRUM
encourages you to have some idea of what the final result will be, even
if each phase is scoped opportunistically.
KWW
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
