On Wed, Dec 3, 2008 at 4:58 AM, Gerard Meijssen <[EMAIL PROTECTED]> 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. _______________________________________________ foundation-l mailing list [email protected] Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
