On Wed, Dec 3, 2008 at 4:58 AM, Gerard Meijssen
<gerard.meijssen(a)gmail.com> wrote:
Hoi,
I had a look. It is based on templates. What templates do wonderfully is
create a proof of concept.
I agree. My concern is that we should not jump first into writing
software unless a proof of concept is not possible. We will not get
the software right the first time, fewer people have the skills needed
to change the software, etc. The first priority is obtaining a good
understanding of what works through prototyping, but we fail at that.
The possibility of future software is used as an argument against any
prototyping.
When you mention the "taboo" of rejection by
a community, I can tell you
that this is one thing that I talk about quite often. Now rejection should
be based on arguments and it is important to understand the arguments WHY
things are proposed and the arguments WHY proposals are rejected. When
people just vote, there is nothing that helps in understanding the reasons
why, there is no handle on the argument that will help with preventing the
negative effects of a proposal.
English Wikipedia, as a high profile example, simply does not want to
encourage new users to create articles. In fact, over time they have
intentionally increased the barrier to create new articles: You now
must have an account for 4 days and make 10 edits before you can
create an article on EnWP. If you've made it that far without being
blocked you probably do not need the wizard.
Arguments made include positions backed by solid fact such as "The
overwhelming majority of contributions by inexperienced people are
very low quality" as well as less factual but hard to argue against
positions such as "We do not know what effect this may have, but it
could be very bad, and we may never be able to turn it off".
I would like to think this class of problems is unique to English
Wikipedia, but I've seen it to varying degrees in other communities
which use super-majority as the decision criteria, and I suspect that
it may be the fate of many projects as they mature.
When one community rejects a proposal, new
functionality does not need to be rejected by other communities. Extensions
do not need to be enabled.
This is true. But it's poor use of resources to churn out feature
after feature that many communities will reject.
[snip]
When you are talking about "inflexible"
solutions, you have to appreciate
that you are capable of creating the most wonderful templates.
[snip]
I'm not wed to the concept of templates, and certainly not to their
implementation today. If you search the lists you'll find cases of me
ranting about "edit this page" bringing up two screens of
template-gunk on many articles.
What I am strongly opposed to is our practice of inventing
functionality in a near-vacuum and throwing it out as faite accomplis.
Not only do I believe that you, me, and the other kind residents of
this list are unqualified to produce perfect solutions to complex
social-technical issue in a single pass, I believe no one is.
The questions for any new non-trivial functionality should be:
(1) Can you prototype it or study it without software changes and
learn more about what we really need?
(2) Have you tried alternative solutions?
(3) From your prototyping what evidence do you have for and against
the proposed changes?
(4) Is there a more minimal software change which would address this
need in a generic manner and facilitate more learning and prototyping?
We ask none of these today. Instead, temporary solutions are widely
rejected because some undefined software solution will be available
"any day now", which either never comes, or when it does come is not
activated because people believe that it fails to meet the
requirements because no one took the effort to really understand and
define the requirements.