I would like to see this as a separate namespace for the reasons given by the proponents, but I share the concern about the disruption in switching over. I suspect it would be a lot of work, even with a lot of bot help. I suggest more analysis about how exactly the conversion would be done might help.
Larry Pieniazek Work mail: lpieniaz at us.ibm.com Hobby mail: lar at miltontrainworks.com
As the old saying goes, "never touch a running system" :D
Although surely a project namespace would be convenient, I don't think it is worth all the workload.
Regards, Aetherfukz
On 08/02/07, Larry Pieniazek lar@miltontrainworks.com wrote:
I would like to see this as a separate namespace for the reasons given by the proponents, but I share the concern about the disruption in switching over. I suspect it would be a lot of work, even with a lot of bot help. I suggest more analysis about how exactly the conversion would be done might help.
Larry Pieniazek Work mail: lpieniaz at us.ibm.com Hobby mail: lar at miltontrainworks.com
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l
On 2/8/07, Christof Sperl christof.sperl@gmail.com wrote:
Although surely a project namespace would be convenient, I don't think it is worth all the workload.
But different people say the "workload" is minimal. Whom is correct?
-SV
On 2/9/07, Christof Sperl christof.sperl@gmail.com wrote:
As the old saying goes, "never touch a running system" :D
A bit off topic, but... There must be a contrary saying somewhere. My day job currently involves undoing the progressive harm caused by generations of programmers refusing to touch a running system, instead preferring to add layer upon layer of workaround. If only they'd had the guts to actually rewrite the system each time rather than ph33ring it, we would have ended up with one single program of 200 lines of code, rather than 5 programs in 5 different languages each of 200 lines of code.
Steve
On 2/9/07, Steve Bennett stevagewp@gmail.com wrote:
A bit off topic, but... There must be a contrary saying somewhere.
A stich in time saves nine
My day job currently involves undoing the progressive harm caused by generations of programmers refusing to touch a running system, instead preferring to add layer upon layer of workaround. If only they'd had the guts to actually rewrite the system each time rather than ph33ring it, we would have ended up with one single program of 200 lines of code, rather than 5 programs in 5 different languages each of 200 lines of code.
Steve
The cynical side of my says that is more to do with people wanting job security. Mind you I have the same view about much of copyright law.
On 2/10/07, geni geniice@gmail.com wrote:
The cynical side of my says that is more to do with people wanting job security. Mind you I have the same view about much of copyright law.
Eh, no. If you want job security you redesign everything you can get your paws on, so you're the only one who understands how everything works. Leaving things alone makes you replaceable.
Steve
Steve Bennett wrote:
On 2/10/07, geni geniice@gmail.com wrote:
The cynical side of my says that is more to do with people wanting job security. Mind you I have the same view about much of copyright law.
Eh, no. If you want job security you redesign everything you can get your paws on, so you're the only one who understands how everything works. Leaving things alone makes you replaceable.
Yeah, you're right, it's just fear. Fear and laziness.
The few programmers I've met who are both entirely cynical about their work and socially adept enough to be manipulative don't seem to want to code their way into a lifetime of bug fixes. Instead, they'll become evil managers or jealous guardians of key knowledge. But they won't intentionally make a mess.
Interestingly, and bringing this almost back on topic, it's our own Ward Cunningham who gave me my best tool in fighting that death-by-cruft pattern: the concept of code debt.
The people paying the bills don't care much about abstract notions of quality, especially the sort of mysterious under-the-hood quality that they can't see. But if you talk about programmers building up debt, and the interest you pay in having to touch high-debt code, they start to get it. And then when you tell them that if the total debt ever rises above the value of the code, that's when you have to declare project bankruptcy and start from scratch, that really makes their eyes light up.
Suddenly, instead of bad code being a vague problem for programmers to deal with by working harder, it's a financial issue, a debt that is getting in the way of something they want.
William
The way to do it would be to change the mediawiki default $wgSitename (in Defaults.php I think) from "Project" to "Namespace", and free up Project to be used for something useful like Wikipedia:Wikiprojects.
-SV Damn, forgot to capitalise: Wikipedia:WikiProjects
On 2/8/07, Larry Pieniazek lar@miltontrainworks.com wrote:
I would like to see this as a separate namespace for the reasons given by the proponents, but I share the concern about the disruption in switching over. I suspect it would be a lot of work, even with a lot of bot help. I suggest more analysis about how exactly the conversion would be done might help.
Larry Pieniazek Work mail: lpieniaz at us.ibm.com Hobby mail: lar at miltontrainworks.com
WikiEN-l mailing list WikiEN-l@lists.wikimedia.org To unsubscribe from this mailing list, visit: http://lists.wikimedia.org/mailman/listinfo/wikien-l