On Wed, Jul 2, 2008 at 10:16 AM, Gerard Meijssen <gerard.meijssen(a)gmail.com> wrote: we An essential part of evaluating any proposal is evaluating whether the basic idea of the proposal is flawed in some important way. If flawed solutions are adopted just because people have already put the work into them, more and more work will be put into them over time, papering over their flaws without really addressing them. Similar specific solutions will be adopted for similar problems, requiring yet more work. The end result will require more work and be less useful than if the original work had been scrapped for its flaws to begin with. For an example, consider user rights changes. When developers stopped changing ranks and that privilege was divested onto stewards and bureaucrats, stewards got Special:UserRights and bureaucrats got Special:MakeSysop. MakeSysop was a narrow and inflexible solution: it was an entire extension, an entire different interface and code base, to do a subset of what UserRights could do. When the desire for more flexibility arose, like the ability to assign bot rights, Special:MakeBot was written. Every time more flexibility was required, it couldn't be provided; it simply couldn't be added without writing and reviewing a whole new extension. Proposals for rollback groups and all sorts of other things simply died because there was no way to implement them. Only years later did some developers (in fact, me, and Werdna) decide a more flexible system would be useful. This obsoleted all the work that had gone into MakeSysop, MakeBot, GiveRollback, and so on, and probably took less work than went into them to begin with. It opened up many new options and was overall a greatly superior solution. If people had said, from the beginning, "Wait, why are we writing an extension that only gives sysop/bureaucrat when we could put in the extra effort to make it properly flexible?", many developer-hours would have been saved, and communities would have gotten the ability to configure their rights much more flexibly years earlier than they did. When a solution is presented that's too narrow, it should be rejected, regardless of how well it achieves its task. Accepting a flawed solution because it sort of works well enough is a recipe for wasting a huge amount of time and effort down the road. Do it once and do it *right*. The ability to localize and import templates from some common location (Commons may make the most sense, not Meta) would be vastly more valuable and more straightforward than this as well. We shouldn't compromise for such a greatly inferior solution. "Works well enough" is not acceptable in any software project with standards. On Wed, Jul 2, 2008 at 10:27 AM, Ilmari Karonen <nospam(a)vyznev.net> wrote: Except that people won't, if what they have isn't completely broken. The absence of functionality is the best drive for improvement. It's all too easy to get some basic functionality up and then lose interest in revamping it so it really works right, when the path of least resistance is to build incrementally on the flawed base that's already present. On Wed, Jul 2, 2008 at 10:47 AM, Andrew Whitworth <wknight8111(a)gmail.com> wrote: I think you'll find that when a flexible new feature becomes available, people will find a lot of unexpected uses for it. Some random thoughts: * People could transclude their user page from Commons to all wikis they have accounts at. (Okay, this is better served by a global user page.) * Userboxes other than Babel could be centralized. * Copyright templates. Copyright policy is typically pretty uniform across projects of the same language, and at a minimum, things like "this work is in the public domain because it was published in the United States before 1923" should be more or less universal. (Well, except in non-US countries that don't recognize the rule of the shorter term, but you see the point.) * Help pages could be transcluded instead of being manually copied as they are now. * Miscellaneous helper templates like {{!}}, {{-}}, {{infobox}}, etc. * And, of course, Babel! There are probably quite a few other things I couldn't immediately think of. On Wed, Jul 2, 2008 at 11:39 AM, Gerard Meijssen <gerard.meijssen(a)gmail.com> wrote: it for this Did you actually ask for comments before the functionality was finished? I remember noticing all the commits to Babel and thinking "Hey, I wonder what that new extension is that all these people are working on." I read every post on Wikitech-l and I'm pretty sure I would have remembered had anything been posted there at or around that time about the proposal. On Wed, Jul 2, 2008 at 4:29 PM, Andrew Whitworth <wknight8111(a)gmail.com> wrote: MakeSysop was a pretty well optimal solution to the problem that it was trying to solve, too. The issue was that it was trying to solve the wrong problem. The same applies here. For all I know, Babel is a flawless fix for what it tries to do, but I don't care, because it's trying to do the wrong thing. If updating from BetaWiki is so important, that could be part of a transclusion-based solution. Such functionality would be useful for more than just Babel templates. In practice I don't know why it would be such an advantage over editing the stuff on Commons or Meta or wherever. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l