Hoi,
As it is the current talk pages are horrible. You gloss over this fact
because you are so fired up about the potential of "end users can
build new features and flows on top of it, without the need to request
the platform
developers to build support for them". Then you attack flow because some
specifications are not there yet. In a previous mail it was said that much
of the UI is very much under development, any discussion is to be taken
with a table spoon of salt.
REALLY the current talk system is horrible on desktops, it is atrocious on
mobiles. Your suggestion is to be dismissed with prejudice because it is so
obviously wrong in so many ways.. I do not care about a possible potential
of a broken system at all I may want to think about features that are
actively used in this broken system.
Thanks,
GerardM
On 7 September 2014 07:57, Diego Moya <dialmove(a)gmail.com> wrote:
These are just
assertions, however. I liked your earlier comments
because they are testable against the architecture (even if the
current implementation, early as it is, will fail many of these
tests). What real world needs cannot be met by a comment-centric
architecture for .. commenting? How important are they?
Erik, a major property of a document-centric architecture that is lost in a
structured one is that it's open-ended, which means that end users can
build new features and flows on top of it, without the need to request the
platform developers to build support for them (sometimes even without
writing new software at all; new workflows can be designed and maintained
purely through social convention).
That's not something that's easy to do when the basic raw material for
communication is split into comments and compartmentalized as table records
with different owners. Such change means that a community that now can
handle their own growth is made to utterly depend on the developers as
gatekeepers for its expansion. In a project where the development team is
understaffed, that's not a healthy proposition.
Sure, you have proposed a Workflow management system in the works, but with
all respect that's pie in the sky. That possibility is under-specified,
would require a lot of research and development with unclear goals and
requirements, and there's no guarantee that it would ever be fit for the
purpose. Please understand why we are wary of such proposal as the solution
for all the flexibility requirements.
Sincerely, it looks like you have this grand vision on how a comment
platform should work, and there's this blind spot to it. Despite repeated
attempts by several experienced editors trying to explain to you how this
architectural change would affect the essence of the project smooth
operation and well-being, you dismiss them by focusing on a single feature
at a time and missing the forest for the trees.
The point is not how we could replicate this or that feature on Flow, it's
how we allow support for all future workflows that we don't know about yet,
without requiring that software changes are made to the platform for each
new need. We know that Wiki systems are valid platforms to support such
expansion requirements, because we have seen them working; but we don't
know how the structured architecture will behave, and there's no reason to
believe it would work - no other structured system have achieved anything
similar. You ask "how important are these needs"? I tell you they are
*essential* to the community; the existing encyclopedia couldn't have been
built without this openness.
You asked Todd to make requirements that are testable against the
architecture. Well, I have one: how well does it allow end-users to build
new unforeseen workflows without requiring development of ad-hoc software
and changes to the platform?
I hope you give consideration to this argument before dismissing it as
inconsequential. So far it seems that the decision has already been made
and that your question ("Do we want discussions to occur in document mode,
or
in a structured comment mode?") is rhetorical. I hope that this happens not
to be true, and the decision is still open to debate from the community.
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l(a)lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>