On Wed, Jul 2, 2008 at 10:16 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
That is not here and now. At this moment we are considering the implementation of the Babel extension, we are not considering something we did not do.
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@vyznev.net wrote:
"Perfect is the greatest enemy of the good enough." I still haven't looked at the specific extension being proposed, but, assuming it doesn't somehow irreversibly drive us down a dead end, we can always start with what we have and improve it later.
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@gmail.com wrote:
The idea of having a generalized extension for sharing pre-made and pre-localized templates across projects is an interesting one. However, with the exception of these babel templates (and maybe copyright licensing templates), I can't imagine too many templates that are going to be useful across both projects and languages. A more general solution is only desirable if there is a more general class of problems to solve. The idea that it might be nice to be able to share more templates then just Babel is a good one, but the reality is that there are few other templates which could possibly benefit from this.
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@gmail.com wrote:
This discussion is about ... I do not know... There is a Babel extension it works, it is even configurable.. I made the mistake to ask for comments for the last time. It is only now that people wake up to the existence of this functionality and start asking questions that would be appropriate before the functionality was finished.
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@gmail.com wrote:
I would disagree with this assertion about optimality. In addition to standardizing the templates, they will be able to use ISO language codes automatically and update translation text from betawiki. For the problem that this is trying to solve, a simplification to the forrest of babel templates, increase in interlingual participation, and further integration of betawiki translation efforts into this, I would say the extension is a highly optimal solution.
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.
Hoi, When I listen to your rant, I would say that the key issue that you do not address in the functionality that you describe is localisation. The notion that templates will just work everywhere is .. odd. It does not, it will not. Yes, you can have a same template be transcluded but it will still be in the same language. Consequently it will just not be appropriate.
When you suggest that such functionality will be useful, I do agree. I will even suggest that much of what you describe can be achieved with OmegaWiki. OmegaWiki has had its fair share of development, it is currently going through a cycle of revamping the functionality because new technology makes it possible to address issues that could not be addressed before and also we learned things to it.
The bottom line is that the Babel extension provides functionality that is of use now. It is superior to everything that we have at the moment. The two biggest advantages are; it is not a template and it does not add complexity to understanding how to do a wiki. This is of major importance in the small projects... Most of our projects are small. The second major advantage is that it is localised in Betawiki and consequently new Babel information is updated like all other localisations.
When you insist on rejecting the Babel templates, you do so based on a glimmer of an ideal all singing all dancing solution. A same kind of argument would reject changes to the parser when it does not help in getting a GUI based editor. The ability to edit in a GUI will make it so much easier to gain more editors. This is not happening either.
The notion that this is a first time that the Babel template has been discussed is flatly wrong. MinuteElection has discussed this on IRC on several occasions. Pathoschild acknowledges that it has been discussed in the past but he chose to go his own way. In the mean time this functionality provides a better mouse trap and as such it deserves to be implemented.
Thanks, GerardM
On Thu, Jul 3, 2008 at 12:24 AM, Simetrical <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com> wrote:
On Wed, Jul 2, 2008 at 10:16 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
That is not here and now. At this moment we are considering the implementation of the Babel extension, we are not considering something
we
did not do.
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@vyznev.net wrote:
"Perfect is the greatest enemy of the good enough." I still haven't looked at the specific extension being proposed, but, assuming it doesn't somehow irreversibly drive us down a dead end, we can always start with what we have and improve it later.
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@gmail.com wrote:
The idea of having a generalized extension for sharing pre-made and pre-localized templates across projects is an interesting one. However, with the exception of these babel templates (and maybe copyright licensing templates), I can't imagine too many templates that are going to be useful across both projects and languages. A more general solution is only desirable if there is a more general class of problems to solve. The idea that it might be nice to be able to share more templates then just Babel is a good one, but the reality is that there are few other templates which could possibly benefit from this.
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@gmail.com wrote:
This discussion is about ... I do not know... There is a Babel extension
it
works, it is even configurable.. I made the mistake to ask for comments
for
the last time. It is only now that people wake up to the existence of
this
functionality and start asking questions that would be appropriate before the functionality was finished.
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@gmail.com wrote:
I would disagree with this assertion about optimality. In addition to standardizing the templates, they will be able to use ISO language codes automatically and update translation text from betawiki. For the problem that this is trying to solve, a simplification to the forrest of babel templates, increase in interlingual participation, and further integration of betawiki translation efforts into this, I would say the extension is a highly optimal solution.
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Jul 3, 2008 at 12:39 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
[snip /] The notion that this is a first time that the Babel template has been discussed is flatly wrong. MinuteElection has discussed this on IRC on several occasions. Pathoschild acknowledges that it has been discussed in the past but he chose to go his own way. In the mean time this functionality provides a better mouse trap and as such it deserves to be implemented.
Thanks, GerardM
The notion that a discussion on IRC can get the range of views and insight a mailing list can is also flatly wrong.
It was _not_ brought up publicly (on mailing lists, etc.), and thus the community lacked the chance to give input. I saw commit messages go by for an extension, but I do not automatically go look into it (many extensions are of no interest to me, I would not, for example, pay attention to a commit to the YouTube extension). Had I known this was coming, I might've been more inclined to follow along and comment before now.
-Chad
Hoi, There is no single way of informing people about something that might be of interest to them. This thread started as a thread to three mailing lists, it is now only visible to developers.
This extension has been documented on Meta, there is info on Mediawiki.org .. it has been discussed on IRC. There have been commits. There will always be people that do not get the message. People that will say that the communication was not good enough because they did not hear of it, because it did not attract their attention. You did not consider the commit messages of interest, that is your problem it is not that this information was not there for you. And yes, there is too much information out there. Thanks, GerardM
On Thu, Jul 3, 2008 at 8:16 AM, Chad innocentkiller@gmail.com wrote:
On Thu, Jul 3, 2008 at 12:39 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
[snip /] The notion that this is a first time that the Babel template has been discussed is flatly wrong. MinuteElection has discussed this on IRC on several occasions. Pathoschild acknowledges that it has been discussed
in
the past but he chose to go his own way. In the mean time this
functionality
provides a better mouse trap and as such it deserves to be implemented.
Thanks, GerardM
The notion that a discussion on IRC can get the range of views and insight a mailing list can is also flatly wrong.
It was _not_ brought up publicly (on mailing lists, etc.), and thus the community lacked the chance to give input. I saw commit messages go by for an extension, but I do not automatically go look into it (many extensions are of no interest to me, I would not, for example, pay attention to a commit to the YouTube extension). Had I known this was coming, I might've been more inclined to follow along and comment before now.
-Chad
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Jul 3, 2008 at 4:02 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, There is no single way of informing people about something that might be of interest to them. This thread started as a thread to three mailing lists, it is now only visible to developers.
This extension has been documented on Meta, there is info on Mediawiki.org .. it has been discussed on IRC. There have been commits. There will always be people that do not get the message. People that will say that the communication was not good enough because they did not hear of it, because it did not attract their attention. You did not consider the commit messages of interest, that is your problem it is not that this information was not there for you. And yes, there is too much information out there. Thanks, GerardM
On Thu, Jul 3, 2008 at 8:16 AM, Chad innocentkiller@gmail.com wrote:
On Thu, Jul 3, 2008 at 12:39 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
[snip /] The notion that this is a first time that the Babel template has been discussed is flatly wrong. MinuteElection has discussed this on IRC on several occasions. Pathoschild acknowledges that it has been discussed
in
the past but he chose to go his own way. In the mean time this
functionality
provides a better mouse trap and as such it deserves to be implemented.
Thanks, GerardM
The notion that a discussion on IRC can get the range of views and insight a mailing list can is also flatly wrong.
It was _not_ brought up publicly (on mailing lists, etc.), and thus the community lacked the chance to give input. I saw commit messages go by for an extension, but I do not automatically go look into it (many extensions are of no interest to me, I would not, for example, pay attention to a commit to the YouTube extension). Had I known this was coming, I might've been more inclined to follow along and comment before now.
-Chad
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
To use a metaphor, it would be like you handing me a large book and then faulting me when I hadn't read the one chapter you wished to discuss. Now, is that my fault for not reading the chapter, or yours, for not indicating it needed to be read?
(sorry about losing some of the lists, it can get confusing which threads have gone where, for that I apologize)
-Chad
Hoi, You can not be expected to read everything nor can you expect that everything that is of interest to you is presented to you in a way that is optimal for you. There has been a genuine effort to involve people, this is clear because there are several ways in which you can find relevant information.
If you or I want to blame the other, we get into a negative spiral, it will gain us nothing. What is at issue is that there is a need that can be fulfilled with the Babel extension and all the necessary parts for it are there. Thanks, GerardM
On Thu, Jul 3, 2008 at 1:54 PM, Chad innocentkiller@gmail.com wrote:
On Thu, Jul 3, 2008 at 4:02 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, There is no single way of informing people about something that might be
of
interest to them. This thread started as a thread to three mailing lists,
it
is now only visible to developers.
This extension has been documented on Meta, there is info on
Mediawiki.org
.. it has been discussed on IRC. There have been commits. There will
always
be people that do not get the message. People that will say that the communication was not good enough because they did not hear of it,
because
it did not attract their attention. You did not consider the commit
messages
of interest, that is your problem it is not that this information was not there for you. And yes, there is too much information out there. Thanks, GerardM
On Thu, Jul 3, 2008 at 8:16 AM, Chad innocentkiller@gmail.com wrote:
On Thu, Jul 3, 2008 at 12:39 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
[snip /] The notion that this is a first time that the Babel template has been discussed is flatly wrong. MinuteElection has discussed this on IRC on several occasions. Pathoschild acknowledges that it has been
discussed
in
the past but he chose to go his own way. In the mean time this
functionality
provides a better mouse trap and as such it deserves to be
implemented.
Thanks, GerardM
The notion that a discussion on IRC can get the range of views and insight a mailing list can is also flatly wrong.
It was _not_ brought up publicly (on mailing lists, etc.), and thus the community lacked the chance to give input. I saw commit messages go by for an extension, but I do not automatically go look into it (many extensions are of no interest to me, I would not, for example, pay attention to a commit to the YouTube extension). Had I known this was coming, I might've been more inclined to follow along and comment before now.
-Chad
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
To use a metaphor, it would be like you handing me a large book and then faulting me when I hadn't read the one chapter you wished to discuss. Now, is that my fault for not reading the chapter, or yours, for not indicating it needed to be read?
(sorry about losing some of the lists, it can get confusing which threads have gone where, for that I apologize)
-Chad
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org