Mailing List Archive

Hello Tim,

I definitively like to see things develop in the direction you
described. That would make the templates more useful, either for the
editors but also for the readers and other developers who can datamine
the Wikimedia-project entries. And at some point we must simply ignore
the desire of the template-developers and go in a direction that would
be beneficial for the majority of the editors and users.

Ting

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

The discussion to add a full-fledged programming language to MediaWiki is
yet another example of this. Rather than evaluate existing tools which allow
for user-interface extensibility, the developers would rather embed PHP
within PHP. This allows you to do a variety of things:

* Simulate the brain
* Write MediaWiki within MediaWiki
* Compute any function
* ...
* Write an enyclopedia?

Our neural simulator contains an embedded dynamic language called C^c. It is
interpreted C++. I assure you that it does not aid in usability. Our
software did not start to become truly usable until we tackled the issue of
user-extensible interfaces.

This issue has already been tackled in MediaWiki, and yet the solution to
all of our problems is claimed to be a well-designed embedded scripting
language. This is the largest possible hammer you could apply to the
problem. I can't see how it is a reasonable next step.

2009/1/15 Brian <Brian.Mingus@colorado.edu>

> Access to svn does not imply access to MediaWiki. Changes to MediaWiki have
> been almost entirely up to core developer discretion, and as I have
> demonstrated, 'consensus' has largely implied that they, and only they,
> thought the changes made Wikipedia better. The ideas are rarely presented to
> the community in a formal, well-designed demo format (as SMW has been, time
> and time again), and they are not evaluated for their usability. When a
> usability issue arises third party tools are not properly considered.
> Rather, they reinvent the wheel in an inferior manner.
>
>
> On Thu, Jan 15, 2009 at 11:07 AM, Denny Vrandeèiæ <
> dvr@aifb.uni-karlsruhe.de> wrote:
>
>> That's pretty much exactly what Semantic MediaWiki offers.
>>
>> SMW has developed a lot, since many of you saw it. By now, you may
>> * switch off inline queries if you are afraid they won't work fast enough
>> * get rid of the ugly syntax everyone is scared about (and simply hide
>> it all in templates by using the #declare function)
>> * have all that data sitting there inside the DB and export it in
>> standard data formats like RDF or JSON (ok, well, the last one is
>> *almost* finished)
>>
>> We would be very much interested in having SMW tested on a labs machine
>> with a copy of a reasonably big Wikipedia (e.g. German).
>>
>> And, just to take note to the title of this thread -- I never thought
>> and the developers never gave me the feeling that the software is out of
>> reach for the community. Access to SVN was swiftly granted, and both Tim
>> and Brion were always giving encouraging and valuable feedback to us.
>>
>> Cheers,
>> denny
>>
>> Magnus Manske wrote:
>> > On Wed, Jan 14, 2009 at 9:57 AM, Nikola Smolenski <smolensk@eunet.yu>
>> wrote:
>> >> David Gerard wrote:
>> >>> The other useful thing that can be done with templates is to
>> >>> standardise the field names in them as much as possible per wiki.
>> >>>
>> >>> The reason? To enhance machine readability of data in them. People are
>> >>> SERIOUSLY INTERESTED in this.
>> >> Another useful thing: after an article is parsed, write all the
>> >> templates it uses and their parameters in the database. Even if at
>> first
>> >> it isn't possible to read this data on Wikipedia, Toolserver could do
>> >> wonders with it :)
>> >
>> > People (including yours truly) have been asking for this for years...
>> >
>> > Magnus
>> >
>> > _______________________________________________
>> > foundation-l mailing list
>> > foundation-l@lists.wikimedia.org
>> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>>
>> _______________________________________________
>> foundation-l mailing list
>> foundation-l@lists.wikimedia.org
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>>
>
>
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

2009/1/15 Brian <Brian.Mingus@colorado.edu>

> Access to svn does not imply access to MediaWiki. Changes to MediaWiki have
> been almost entirely up to core developer discretion, and as I have
> demonstrated, 'consensus' has largely implied that they, and only they,
> thought the changes made Wikipedia better. The ideas are rarely presented
> to
> the community in a formal, well-designed demo format (as SMW has been, time
> and time again), and they are not evaluated for their usability. When a
> usability issue arises third party tools are not properly considered.
> Rather, they reinvent the wheel in an inferior manner.
>

Maybe I'm the only one thinking this...but if you see problems,
why don't you try to get involved fixing them? Saying "we have
problems, and you guys won't listen to us" isn't helpful, it's just
complaining. If you have such an enlightened opinion as to the
state of usability within MediaWiki, why not get involved and
share said wisdom?

As many people have said earlier in this thread: the developers
create no barriers to helping with the software. Us getting involved
with all of the various wiki communities every time a change is
proposed would be counter-productive--I for one don't want to
get into an enwiki debate over the placement of a button on
the preferences page. Just as you don't expect Commons to come
and ask every wiki if they think an image should be deleted, don't
expect the developers to come and ask the community for their
blessing every time something needs changing.

-Chad
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Chad,

What more would you like me to do, specifically? I have attended the
conferences, I am aware of the MediaWiki development process and I am
pointing towards high-quality code that meets every possible standard the
community could reasonably ask. The most important of those standards is
that the design was very well thought out and presented to the community
over a period of years. At the same time many features which have come to be
known as mainstays of Wikipedia have been snuck into the source code with
far less effort.

In this discussion I have expressed feelings I have had for years, and now
that there is money on the table, I believe it is time we got to the heart
of the issue. I am pointing to the MediaWiki development process being
broken as a core part of that issue.

I reject many of the excuses that have been presented. For example:

- Developers didn't have the time

When one considers the period of years that we are talking about this
certainly appears to be false.

- Users were already doing this, so we just made it easier for them

This is patently false - that particular advanced users are doing something
*does not imply consensus.* Before ParserFunctions were implemented
consensus should have been checked. Specifically, I believe a design should
have been presented at Wikimania so that everyone had a chance to evaluate
them. My experience has been that the community looks down on templates.
That these templates were hurting the servers is a great opportunity to ask
the community what the best solution is. Was the best solution to ingrain
templates into Wikipedia by making them even easier to use, or to remove
them altogether in favor of some alternate technology? That discussion was
simply not had. And ParserFunctions is just one such example.

- Show us the code - why don't you just fix the problem?

I do not consider writing code to be an impediment to design and process
discussions. Furthermore, it would be suggested that I implement the code as
an extension so that it might be ignored by the core developers along with
every other extension. Lastly, the code has already been written. If it is
not production-ready it is at the very least an excellent demo. This is also
related to the 'Developers didn't have the time' issue. I fully believe that
the core developers could reimplement various extensions in a scalable
manner in relatively short order - they are, after all, crack php coders.
The real problem is that they do not have the incentive. They have been
given the keys and the community has not been given a voice. When a
community member writes code to help MediaWiki, its put into the archives of
extensions and quickly made obsolete by changes to core MediaWiki code.

On Thu, Jan 15, 2009 at 11:40 AM, Chad <innocentkiller@gmail.com> wrote:

> 2009/1/15 Brian <Brian.Mingus@colorado.edu>
>
> > Access to svn does not imply access to MediaWiki. Changes to MediaWiki
> have
> > been almost entirely up to core developer discretion, and as I have
> > demonstrated, 'consensus' has largely implied that they, and only they,
> > thought the changes made Wikipedia better. The ideas are rarely presented
> > to
> > the community in a formal, well-designed demo format (as SMW has been,
> time
> > and time again), and they are not evaluated for their usability. When a
> > usability issue arises third party tools are not properly considered.
> > Rather, they reinvent the wheel in an inferior manner.
> >
>
> Maybe I'm the only one thinking this...but if you see problems,
> why don't you try to get involved fixing them? Saying "we have
> problems, and you guys won't listen to us" isn't helpful, it's just
> complaining. If you have such an enlightened opinion as to the
> state of usability within MediaWiki, why not get involved and
> share said wisdom?
>
> As many people have said earlier in this thread: the developers
> create no barriers to helping with the software. Us getting involved
> with all of the various wiki communities every time a change is
> proposed would be counter-productive--I for one don't want to
> get into an enwiki debate over the placement of a button on
> the preferences page. Just as you don't expect Commons to come
> and ask every wiki if they think an image should be deleted, don't
> expect the developers to come and ask the community for their
> blessing every time something needs changing.
>
> -Chad
> _______________________________________________
> foundation-l mailing list
> foundation-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

I have one more:

- Developers don't have to wait for community consensus before
implementing changes. Developers don't have to wait for the community to
vote on every line of code.

This is obviously not something I have suggested, so its not a very good
argument against the process being broken. My argument applies largely to
major changes in MediaWiki - and yes, major changes have been snuck into
MediaWiki without consensus.

On Thu, Jan 15, 2009 at 12:19 PM, Brian <Brian.Mingus@colorado.edu> wrote:

> Chad,
>
> What more would you like me to do, specifically? I have attended the
> conferences, I am aware of the MediaWiki development process and I am
> pointing towards high-quality code that meets every possible standard the
> community could reasonably ask. The most important of those standards is
> that the design was very well thought out and presented to the community
> over a period of years. At the same time many features which have come to be
> known as mainstays of Wikipedia have been snuck into the source code with
> far less effort.
>
> In this discussion I have expressed feelings I have had for years, and now
> that there is money on the table, I believe it is time we got to the heart
> of the issue. I am pointing to the MediaWiki development process being
> broken as a core part of that issue.
>
> I reject many of the excuses that have been presented. For example:
>
> - Developers didn't have the time
>
> When one considers the period of years that we are talking about this
> certainly appears to be false.
>
> - Users were already doing this, so we just made it easier for them
>
> This is patently false - that particular advanced users are doing something
> *does not imply consensus.* Before ParserFunctions were implemented
> consensus should have been checked. Specifically, I believe a design should
> have been presented at Wikimania so that everyone had a chance to evaluate
> them. My experience has been that the community looks down on templates.
> That these templates were hurting the servers is a great opportunity to ask
> the community what the best solution is. Was the best solution to ingrain
> templates into Wikipedia by making them even easier to use, or to remove
> them altogether in favor of some alternate technology? That discussion was
> simply not had. And ParserFunctions is just one such example.
>
> - Show us the code - why don't you just fix the problem?
>
> I do not consider writing code to be an impediment to design and process
> discussions. Furthermore, it would be suggested that I implement the code as
> an extension so that it might be ignored by the core developers along with
> every other extension. Lastly, the code has already been written. If it is
> not production-ready it is at the very least an excellent demo. This is also
> related to the 'Developers didn't have the time' issue. I fully believe that
> the core developers could reimplement various extensions in a scalable
> manner in relatively short order - they are, after all, crack php coders.
> The real problem is that they do not have the incentive. They have been
> given the keys and the community has not been given a voice. When a
> community member writes code to help MediaWiki, its put into the archives of
> extensions and quickly made obsolete by changes to core MediaWiki code.
>
>
> On Thu, Jan 15, 2009 at 11:40 AM, Chad <innocentkiller@gmail.com> wrote:
>
>> 2009/1/15 Brian <Brian.Mingus@colorado.edu>
>>
>> > Access to svn does not imply access to MediaWiki. Changes to MediaWiki
>> have
>> > been almost entirely up to core developer discretion, and as I have
>> > demonstrated, 'consensus' has largely implied that they, and only they,
>> > thought the changes made Wikipedia better. The ideas are rarely
>> presented
>> > to
>> > the community in a formal, well-designed demo format (as SMW has been,
>> time
>> > and time again), and they are not evaluated for their usability. When a
>> > usability issue arises third party tools are not properly considered.
>> > Rather, they reinvent the wheel in an inferior manner.
>> >
>>
>> Maybe I'm the only one thinking this...but if you see problems,
>> why don't you try to get involved fixing them? Saying "we have
>> problems, and you guys won't listen to us" isn't helpful, it's just
>> complaining. If you have such an enlightened opinion as to the
>> state of usability within MediaWiki, why not get involved and
>> share said wisdom?
>>
>> As many people have said earlier in this thread: the developers
>> create no barriers to helping with the software. Us getting involved
>> with all of the various wiki communities every time a change is
>> proposed would be counter-productive--I for one don't want to
>> get into an enwiki debate over the placement of a button on
>> the preferences page. Just as you don't expect Commons to come
>> and ask every wiki if they think an image should be deleted, don't
>> expect the developers to come and ask the community for their
>> blessing every time something needs changing.
>>
>> -Chad
>> _______________________________________________
>> foundation-l mailing list
>> foundation-l@lists.wikimedia.org
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>>
>
>
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

2009/1/15 Brian <Brian.Mingus@colorado.edu>:
> The discussion to add a full-fledged programming language to MediaWiki is
> yet another example of this. Rather than evaluate existing tools which allow
> for user-interface extensibility, the developers would rather embed PHP
> within PHP. This allows you to do a variety of things:
>
> * Simulate the brain
> * Write MediaWiki within MediaWiki
> * Compute any function
> * ...
> * Write an enyclopedia?
>
> Our neural simulator contains an embedded dynamic language called C^c. It is
> interpreted C++. I assure you that it does not aid in usability. Our
> software did not start to become truly usable until we tackled the issue of
> user-extensible interfaces.
>
> This issue has already been tackled in MediaWiki, and yet the solution to
> all of our problems is claimed to be a well-designed embedded scripting
> language. This is the largest possible hammer you could apply to the
> problem. I can't see how it is a reasonable next step.

Brian,

You've been advocating Semantic Mediawiki, which would address a
certain set of issues. However, I don't see how that would make the
template / parser function syntax any less cumbersome (actually,
adding semantic tags would probably make template code marginally more
complicated). So, it would appear to me that the question of how to
make templates more usable is separate from the question of whether to
enable Semantic Mediawiki.

Did you have a different solution to the template / parser function
usability issues? What existing tools might you suggest for making
things like Template:Infobox [1] and Template:Cite_web [2] more
accessible?

-Robert Rohde

[1] http://en.wikipedia.org/wiki/Template:Infobox
[2] http://en.wikipedia.org/wiki/Template:Cite_web

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Hello Brian,

thanks for all your insights, bashing and vocal support of your pet
ideas.

I understand, that SMW is academically interesting concept (though
there're contradicting ideas in academia too, suggesting natural
language processing as an alternative, and this seems where currently
research tries to go too), and it provides "usability" in niche cases
(academic data crunching).

I fail to see why you associate SMW with general usability we're
trying to think about? Is that something we simple mortals cannot
understand, or are you simply out of touch from reality?

See, our project is special.

a) We have mass collaboration at large
b) We end up having mass collaboration on individual articles and topics
c) We have mega-mass readership
d) We have massive scope and depth

And, oh well, we have to run software development to facilitate all
that. As you may notice, the above list puts quite some huge
constraints on what we can do.
All our features end up being incremental, and even though in theory
they are easy to revert, it is the mass collaboration that picks it up
and moves to a stage where it is not that easy (and that happens
everywhere, where lots of work is being done).

So, you are attacking templates, which have helped to deal with nearly
everything we do (and are tiny, compared to overall content they
facilitate), and were part of incremental development of the site and
where editing community was going. Of course, there are ways to make
some of our template management way better (template catalogues, more
visual editing of parameters, less special characters for casual
editors), but they generally are how we imagine and do information
management.

Now, if you want to come up with academic attitudes, and start telling
how ontology is important, and all the semantic meanings have to be
highlighted, sure, go on, talk to community, they can do it without
software support too - by normalizing templates, using templates for
tagging relations, then use various external tools to build
information overlays on top of that. Make us believe stuff like that
has to be deployed by showing initiative in the communities, not by
showing initiative by external parties.

Once it comes to actual software engineering, we have quite limited
resources, and quite important mandate and cause.
We have to make sure, that readers will be able to read, editors will
be able to edit, and foundation will still be able to support the
project.
We may not always try to be exceptionally perfect (Tim does ;-), but
that is because we do not want to be too stressed either.

So, when it comes to reader community, software is doing work for
them. Some of readers end up engineering software to make it better.
When it comes to editing community, software does the work for them.
Some of editors end up engineering software to make it better.

Which community are you talking about?

BR,
--
Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]



_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Domas, that is an unfair characterization of my e-mails, which I do not
believe you have read in full.

I have only advocated SMW + SF as a method of allowing users to extend the
user interface. I am not interested in SMW for "academic data crunching."
DBPedia is wonderful project for people with those interests. Mine are in
modeling the brain, and I have in the past tried to predict wikipedia's
quality. I don't know if you were at that talk, but I believe I remember you
at that conference.

I don't care all that much about ontologies. I am not a semantic web guru. I
have pointed out that these technologies provide a means for users to design
the interfaces and that these technologies have been overlooked by
developers. They do not provide usability in niche cases, which you would
know had you read my e-mails. They potentially improve usability in 75% of
articles by providing custom tailored user interfaces.

But had you read my e-mails you would also know that I do not advocate
enabling the extensions unmodified, but giving them proper consideration and
refactoring the minimalist set of features that would be useful into
something that is scalable.

That is, I want to discuss the how the process of adding new features to
MediaWiki is broken, and how this has been a specific example.


On Mon, Jan 19, 2009 at 7:31 AM, Domas Mituzas <midom.lists@gmail.com>wrote:

> Hello Brian,
>
> thanks for all your insights, bashing and vocal support of your pet
> ideas.
>
> I understand, that SMW is academically interesting concept (though
> there're contradicting ideas in academia too, suggesting natural
> language processing as an alternative, and this seems where currently
> research tries to go too), and it provides "usability" in niche cases
> (academic data crunching).
>
> I fail to see why you associate SMW with general usability we're
> trying to think about? Is that something we simple mortals cannot
> understand, or are you simply out of touch from reality?
>
> See, our project is special.
>
> a) We have mass collaboration at large
> b) We end up having mass collaboration on individual articles and topics
> c) We have mega-mass readership
> d) We have massive scope and depth
>
> And, oh well, we have to run software development to facilitate all
> that. As you may notice, the above list puts quite some huge
> constraints on what we can do.
> All our features end up being incremental, and even though in theory
> they are easy to revert, it is the mass collaboration that picks it up
> and moves to a stage where it is not that easy (and that happens
> everywhere, where lots of work is being done).
>
> So, you are attacking templates, which have helped to deal with nearly
> everything we do (and are tiny, compared to overall content they
> facilitate), and were part of incremental development of the site and
> where editing community was going. Of course, there are ways to make
> some of our template management way better (template catalogues, more
> visual editing of parameters, less special characters for casual
> editors), but they generally are how we imagine and do information
> management.
>
> Now, if you want to come up with academic attitudes, and start telling
> how ontology is important, and all the semantic meanings have to be
> highlighted, sure, go on, talk to community, they can do it without
> software support too - by normalizing templates, using templates for
> tagging relations, then use various external tools to build
> information overlays on top of that. Make us believe stuff like that
> has to be deployed by showing initiative in the communities, not by
> showing initiative by external parties.
>
> Once it comes to actual software engineering, we have quite limited
> resources, and quite important mandate and cause.
> We have to make sure, that readers will be able to read, editors will
> be able to edit, and foundation will still be able to support the
> project.
> We may not always try to be exceptionally perfect (Tim does ;-), but
> that is because we do not want to be too stressed either.
>
> So, when it comes to reader community, software is doing work for
> them. Some of readers end up engineering software to make it better.
> When it comes to editing community, software does the work for them.
> Some of editors end up engineering software to make it better.
>
> Which community are you talking about?
>
> BR,
> --
> Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]
>
>
>
> _______________________________________________
> foundation-l mailing list
> foundation-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

This community, which takes quite a bit of effort to communicate with,
effort which I have not seen from the development team:

> Any changes to the software must be gradual and reversible. We need to make
> sure that any changes contribute positively to the community, as ultimately
> determined by everybody in Wikipedia, in full consultation with the
> community consensus. -- Jimbo Wales<http://en.wikipedia.org/wiki/User:Jimbo_Wales>
>


I've been told by a volunteer developer in that this quote is irrelevant. I
wonder how many people believe that is true.

On Mon, Jan 19, 2009 at 7:31 AM, Domas Mituzas <midom.lists@gmail.com>wrote:

> Hello Brian,
>
> thanks for all your insights, bashing and vocal support of your pet
> ideas.
>
> I understand, that SMW is academically interesting concept (though
> there're contradicting ideas in academia too, suggesting natural
> language processing as an alternative, and this seems where currently
> research tries to go too), and it provides "usability" in niche cases
> (academic data crunching).
>
> I fail to see why you associate SMW with general usability we're
> trying to think about? Is that something we simple mortals cannot
> understand, or are you simply out of touch from reality?
>
> See, our project is special.
>
> a) We have mass collaboration at large
> b) We end up having mass collaboration on individual articles and topics
> c) We have mega-mass readership
> d) We have massive scope and depth
>
> And, oh well, we have to run software development to facilitate all
> that. As you may notice, the above list puts quite some huge
> constraints on what we can do.
> All our features end up being incremental, and even though in theory
> they are easy to revert, it is the mass collaboration that picks it up
> and moves to a stage where it is not that easy (and that happens
> everywhere, where lots of work is being done).
>
> So, you are attacking templates, which have helped to deal with nearly
> everything we do (and are tiny, compared to overall content they
> facilitate), and were part of incremental development of the site and
> where editing community was going. Of course, there are ways to make
> some of our template management way better (template catalogues, more
> visual editing of parameters, less special characters for casual
> editors), but they generally are how we imagine and do information
> management.
>
> Now, if you want to come up with academic attitudes, and start telling
> how ontology is important, and all the semantic meanings have to be
> highlighted, sure, go on, talk to community, they can do it without
> software support too - by normalizing templates, using templates for
> tagging relations, then use various external tools to build
> information overlays on top of that. Make us believe stuff like that
> has to be deployed by showing initiative in the communities, not by
> showing initiative by external parties.
>
> Once it comes to actual software engineering, we have quite limited
> resources, and quite important mandate and cause.
> We have to make sure, that readers will be able to read, editors will
> be able to edit, and foundation will still be able to support the
> project.
> We may not always try to be exceptionally perfect (Tim does ;-), but
> that is because we do not want to be too stressed either.
>
> So, when it comes to reader community, software is doing work for
> them. Some of readers end up engineering software to make it better.
> When it comes to editing community, software does the work for them.
> Some of editors end up engineering software to make it better.
>
> Which community are you talking about?
>
> BR,
> --
> Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]
>
>
>
> _______________________________________________
> foundation-l mailing list
> foundation-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Hoi,
I think it is correct. There is also nothing in there stopping Semantic
MediaWiki from going live.
Thanks,
GerardM

2009/1/19 Brian <Brian.Mingus@colorado.edu>

> This community, which takes quite a bit of effort to communicate with,
> effort which I have not seen from the development team:
>
> > Any changes to the software must be gradual and reversible. We need to
> make
> > sure that any changes contribute positively to the community, as
> ultimately
> > determined by everybody in Wikipedia, in full consultation with the
> > community consensus. -- Jimbo Wales<
> http://en.wikipedia.org/wiki/User:Jimbo_Wales>
> >
>
>
> I've been told by a volunteer developer in that this quote is irrelevant. I
> wonder how many people believe that is true.
>
> On Mon, Jan 19, 2009 at 7:31 AM, Domas Mituzas <midom.lists@gmail.com
> >wrote:
>
> > Hello Brian,
> >
> > thanks for all your insights, bashing and vocal support of your pet
> > ideas.
> >
> > I understand, that SMW is academically interesting concept (though
> > there're contradicting ideas in academia too, suggesting natural
> > language processing as an alternative, and this seems where currently
> > research tries to go too), and it provides "usability" in niche cases
> > (academic data crunching).
> >
> > I fail to see why you associate SMW with general usability we're
> > trying to think about? Is that something we simple mortals cannot
> > understand, or are you simply out of touch from reality?
> >
> > See, our project is special.
> >
> > a) We have mass collaboration at large
> > b) We end up having mass collaboration on individual articles and topics
> > c) We have mega-mass readership
> > d) We have massive scope and depth
> >
> > And, oh well, we have to run software development to facilitate all
> > that. As you may notice, the above list puts quite some huge
> > constraints on what we can do.
> > All our features end up being incremental, and even though in theory
> > they are easy to revert, it is the mass collaboration that picks it up
> > and moves to a stage where it is not that easy (and that happens
> > everywhere, where lots of work is being done).
> >
> > So, you are attacking templates, which have helped to deal with nearly
> > everything we do (and are tiny, compared to overall content they
> > facilitate), and were part of incremental development of the site and
> > where editing community was going. Of course, there are ways to make
> > some of our template management way better (template catalogues, more
> > visual editing of parameters, less special characters for casual
> > editors), but they generally are how we imagine and do information
> > management.
> >
> > Now, if you want to come up with academic attitudes, and start telling
> > how ontology is important, and all the semantic meanings have to be
> > highlighted, sure, go on, talk to community, they can do it without
> > software support too - by normalizing templates, using templates for
> > tagging relations, then use various external tools to build
> > information overlays on top of that. Make us believe stuff like that
> > has to be deployed by showing initiative in the communities, not by
> > showing initiative by external parties.
> >
> > Once it comes to actual software engineering, we have quite limited
> > resources, and quite important mandate and cause.
> > We have to make sure, that readers will be able to read, editors will
> > be able to edit, and foundation will still be able to support the
> > project.
> > We may not always try to be exceptionally perfect (Tim does ;-), but
> > that is because we do not want to be too stressed either.
> >
> > So, when it comes to reader community, software is doing work for
> > them. Some of readers end up engineering software to make it better.
> > When it comes to editing community, software does the work for them.
> > Some of editors end up engineering software to make it better.
> >
> > Which community are you talking about?
> >
> > BR,
> > --
> > Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]
> >
> >
> >
> > _______________________________________________
> > foundation-l mailing list
> > foundation-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
> >
> _______________________________________________
> foundation-l mailing list
> foundation-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Gerard, I'm not sure I understood the full context of your e-mail. There is
only one thing stopping it from going live in my opinion - developer
enthusiasm. I don't think thats how things are supposed to work.

On Mon, Jan 19, 2009 at 11:04 AM, Gerard Meijssen <gerard.meijssen@gmail.com
> wrote:

> Hoi,
> I think it is correct. There is also nothing in there stopping Semantic
> MediaWiki from going live.
> Thanks,
> GerardM
>
> 2009/1/19 Brian <Brian.Mingus@colorado.edu>
>
> > This community, which takes quite a bit of effort to communicate with,
> > effort which I have not seen from the development team:
> >
> > > Any changes to the software must be gradual and reversible. We need to
> > make
> > > sure that any changes contribute positively to the community, as
> > ultimately
> > > determined by everybody in Wikipedia, in full consultation with the
> > > community consensus. -- Jimbo Wales<
> > http://en.wikipedia.org/wiki/User:Jimbo_Wales>
> > >
> >
> >
> > I've been told by a volunteer developer in that this quote is irrelevant.
> I
> > wonder how many people believe that is true.
> >
> > On Mon, Jan 19, 2009 at 7:31 AM, Domas Mituzas <midom.lists@gmail.com
> > >wrote:
> >
> > > Hello Brian,
> > >
> > > thanks for all your insights, bashing and vocal support of your pet
> > > ideas.
> > >
> > > I understand, that SMW is academically interesting concept (though
> > > there're contradicting ideas in academia too, suggesting natural
> > > language processing as an alternative, and this seems where currently
> > > research tries to go too), and it provides "usability" in niche cases
> > > (academic data crunching).
> > >
> > > I fail to see why you associate SMW with general usability we're
> > > trying to think about? Is that something we simple mortals cannot
> > > understand, or are you simply out of touch from reality?
> > >
> > > See, our project is special.
> > >
> > > a) We have mass collaboration at large
> > > b) We end up having mass collaboration on individual articles and
> topics
> > > c) We have mega-mass readership
> > > d) We have massive scope and depth
> > >
> > > And, oh well, we have to run software development to facilitate all
> > > that. As you may notice, the above list puts quite some huge
> > > constraints on what we can do.
> > > All our features end up being incremental, and even though in theory
> > > they are easy to revert, it is the mass collaboration that picks it up
> > > and moves to a stage where it is not that easy (and that happens
> > > everywhere, where lots of work is being done).
> > >
> > > So, you are attacking templates, which have helped to deal with nearly
> > > everything we do (and are tiny, compared to overall content they
> > > facilitate), and were part of incremental development of the site and
> > > where editing community was going. Of course, there are ways to make
> > > some of our template management way better (template catalogues, more
> > > visual editing of parameters, less special characters for casual
> > > editors), but they generally are how we imagine and do information
> > > management.
> > >
> > > Now, if you want to come up with academic attitudes, and start telling
> > > how ontology is important, and all the semantic meanings have to be
> > > highlighted, sure, go on, talk to community, they can do it without
> > > software support too - by normalizing templates, using templates for
> > > tagging relations, then use various external tools to build
> > > information overlays on top of that. Make us believe stuff like that
> > > has to be deployed by showing initiative in the communities, not by
> > > showing initiative by external parties.
> > >
> > > Once it comes to actual software engineering, we have quite limited
> > > resources, and quite important mandate and cause.
> > > We have to make sure, that readers will be able to read, editors will
> > > be able to edit, and foundation will still be able to support the
> > > project.
> > > We may not always try to be exceptionally perfect (Tim does ;-), but
> > > that is because we do not want to be too stressed either.
> > >
> > > So, when it comes to reader community, software is doing work for
> > > them. Some of readers end up engineering software to make it better.
> > > When it comes to editing community, software does the work for them.
> > > Some of editors end up engineering software to make it better.
> > >
> > > Which community are you talking about?
> > >
> > > BR,
> > > --
> > > Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]
> > >
> > >
> > >
> > > _______________________________________________
> > > foundation-l mailing list
> > > foundation-l@lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
> > >
> > _______________________________________________
> > foundation-l mailing list
> > foundation-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
> >
> _______________________________________________
> foundation-l mailing list
> foundation-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Hello!

> Domas, that is an unfair characterization of my e-mails, which I do
> not
> believe you have read in full.

Oh, I did read your emails :-) I think they are unfair
characterization of our development work, which you definitely do not
understand in full.

> But had you read my e-mails you would also know that I do not advocate
> enabling the extensions unmodified, but giving them proper
> consideration and
> refactoring the minimalist set of features that would be useful into
> something that is scalable.

That was happening, that will happen in future, that is happening now,
at one pace or another, depending on various other issues.

> That is, I want to discuss the how the process of adding new
> features to
> MediaWiki is broken, and how this has been a specific example.


You seem to be living in the idea of process, we are a bit on other
side here, more concentrated on productivity.
Indeed, in development team if at least one person agrees with you,
you usually have green light - we manage to trust people, and we do
not want to build stupid obstacles to stop the progress of the project
and the platform.

Only very very bored people can be looking for formal processes to
define formal specifications to find formal consensus.

> This community, which takes quite a bit of effort to communicate with,
> effort which I have not seen from the development team:
> [ Jimmy quote included ]

You know, once upon a time, "full community consultation" was writing
an email to wikipedia-l (thats where everyone subscribed :), and the
three other guys would usually immediately agree with your
modification and say "Jimbo, that is a great idea!" :) The general
traffic is different, community is way bigger, developers are still
same bunch of people, who have to accommodate everyone.

Now it is a bit more complicated, with lots of different communities
out there, the communities themselves partitioned in multiple
subcommunities, people having way different interests, and different
time investment.

By telling you haven't seen any effort you are either blindly
insulting people who are doing the work, or just prove the point, that
whatever communication you're doing, you won't reach everyone (and
certain people will come back later bitching - therefore, ultimate
consensus is unachievable).

By starting this discussion in foundation-l, rather than wikitech-l
(where don't seem to be participating in too many discussions),
indicates you didn't try too much of communications effort yourself
(though, heh, finally I managed to match your face to the name ;-)

Cheers,
--
Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]



_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Hoi.
The Brion is not God. He and the other half gods, have sufficient enthusiasm
for all the weird and wonderful stuff we throw at them. They even spend
considerable effort on Semantic MediaWiki and Denny et al are the first to
acknowledge this and to say that they provided valuable insights. It is not
that they are not enthusiastic, it is that they have a life as well. They
also have to take care of our first priority and that is to make sure that
the show stays on the road.

To get a sense of perspective, the Stanton perspective will take some
890.000 dollar. A large amount indeed but it will not bring all those things
that we would like. The WMF is slowly but surely ramping up the professional
organisation. This organisation will never bring all the things that I want
not what you want. and certainly not all the things that the
communit(y./ies) says (it/they) want(s).
Thanks,
GerardM

2009/1/19 Brian <Brian.Mingus@colorado.edu>

> Gerard, I'm not sure I understood the full context of your e-mail. There is
> only one thing stopping it from going live in my opinion - developer
> enthusiasm. I don't think thats how things are supposed to work.
>
> On Mon, Jan 19, 2009 at 11:04 AM, Gerard Meijssen <
> gerard.meijssen@gmail.com
> > wrote:
>
> > Hoi,
> > I think it is correct. There is also nothing in there stopping Semantic
> > MediaWiki from going live.
> > Thanks,
> > GerardM
> >
> > 2009/1/19 Brian <Brian.Mingus@colorado.edu>
> >
> > > This community, which takes quite a bit of effort to communicate with,
> > > effort which I have not seen from the development team:
> > >
> > > > Any changes to the software must be gradual and reversible. We need
> to
> > > make
> > > > sure that any changes contribute positively to the community, as
> > > ultimately
> > > > determined by everybody in Wikipedia, in full consultation with the
> > > > community consensus. -- Jimbo Wales<
> > > http://en.wikipedia.org/wiki/User:Jimbo_Wales>
> > > >
> > >
> > >
> > > I've been told by a volunteer developer in that this quote is
> irrelevant.
> > I
> > > wonder how many people believe that is true.
> > >
> > > On Mon, Jan 19, 2009 at 7:31 AM, Domas Mituzas <midom.lists@gmail.com
> > > >wrote:
> > >
> > > > Hello Brian,
> > > >
> > > > thanks for all your insights, bashing and vocal support of your pet
> > > > ideas.
> > > >
> > > > I understand, that SMW is academically interesting concept (though
> > > > there're contradicting ideas in academia too, suggesting natural
> > > > language processing as an alternative, and this seems where currently
> > > > research tries to go too), and it provides "usability" in niche cases
> > > > (academic data crunching).
> > > >
> > > > I fail to see why you associate SMW with general usability we're
> > > > trying to think about? Is that something we simple mortals cannot
> > > > understand, or are you simply out of touch from reality?
> > > >
> > > > See, our project is special.
> > > >
> > > > a) We have mass collaboration at large
> > > > b) We end up having mass collaboration on individual articles and
> > topics
> > > > c) We have mega-mass readership
> > > > d) We have massive scope and depth
> > > >
> > > > And, oh well, we have to run software development to facilitate all
> > > > that. As you may notice, the above list puts quite some huge
> > > > constraints on what we can do.
> > > > All our features end up being incremental, and even though in theory
> > > > they are easy to revert, it is the mass collaboration that picks it
> up
> > > > and moves to a stage where it is not that easy (and that happens
> > > > everywhere, where lots of work is being done).
> > > >
> > > > So, you are attacking templates, which have helped to deal with
> nearly
> > > > everything we do (and are tiny, compared to overall content they
> > > > facilitate), and were part of incremental development of the site and
> > > > where editing community was going. Of course, there are ways to make
> > > > some of our template management way better (template catalogues, more
> > > > visual editing of parameters, less special characters for casual
> > > > editors), but they generally are how we imagine and do information
> > > > management.
> > > >
> > > > Now, if you want to come up with academic attitudes, and start
> telling
> > > > how ontology is important, and all the semantic meanings have to be
> > > > highlighted, sure, go on, talk to community, they can do it without
> > > > software support too - by normalizing templates, using templates for
> > > > tagging relations, then use various external tools to build
> > > > information overlays on top of that. Make us believe stuff like that
> > > > has to be deployed by showing initiative in the communities, not by
> > > > showing initiative by external parties.
> > > >
> > > > Once it comes to actual software engineering, we have quite limited
> > > > resources, and quite important mandate and cause.
> > > > We have to make sure, that readers will be able to read, editors will
> > > > be able to edit, and foundation will still be able to support the
> > > > project.
> > > > We may not always try to be exceptionally perfect (Tim does ;-), but
> > > > that is because we do not want to be too stressed either.
> > > >
> > > > So, when it comes to reader community, software is doing work for
> > > > them. Some of readers end up engineering software to make it better.
> > > > When it comes to editing community, software does the work for them.
> > > > Some of editors end up engineering software to make it better.
> > > >
> > > > Which community are you talking about?
> > > >
> > > > BR,
> > > > --
> > > > Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > foundation-l mailing list
> > > > foundation-l@lists.wikimedia.org
> > > > Unsubscribe:
> https://lists.wikimedia.org/mailman/listinfo/foundation-l
> > > >
> > > _______________________________________________
> > > foundation-l mailing list
> > > foundation-l@lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
> > >
> > _______________________________________________
> > foundation-l mailing list
> > foundation-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
> >
> _______________________________________________
> foundation-l mailing list
> foundation-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l