GerardM said:
then again you rationalise why it is not the NIH
syndrome and
you forget about the other arguments why it would be a good thing NOT to
write the same functionality again
Please understand, I have not forgotten about those arguments - I have no
opinion on whether Wikipedia should implement integration with this
service. I'm sorry if there was nay confusion, I am merely hoping to help
enumerate the pros and cons - the pros having already been covered quite
well by others :)
Steve Bennett said:
whereas Picnik integration is a tool for *editors*.
Not
sure if that difference is significant though.
Right. I'm not sure either - I'm just hoping to bring that difference to the
discussion. IMO, the distinction is significant enough to at least consider
as part of the dialog.
So the objection so far seems to boil down to: It
would be even better
if MediaWiki natively had this functionality. I agree. Is that a
reason not to make use of a third party site in the meantime?
Well, the first thing that would need to occur is for someone to create a
MediaWiki extension to encapsulate this functionality. That work can be
initiated immediately, regardless of whether it ever gets used on Wikipedia
or other WMF projects.
I agree that even if WP never adopts the third-party integrated solution, it
would be a nice thing to have this available for other users of the
MediaWiki platform.
Cheers!
-- Jim
On 8/13/07, Steve Bennett <stevagewp(a)gmail.com> wrote:
On 8/13/07, Jim Wilson <wilson.jim.r(a)gmail.com> wrote:
I'm not an expert on how Wikipedia is set up,
however to my knowledge,
these
additions are not tied to the functionality of
the site. That is, if
one of
those services went down, wikipedia would
continue to operate as normal,
just with some broken pages.
Tying actual modification functionality to a third party is a different
matter (IMO). If that photo-edit site went down for a period, then that
functionality would be unavailable for that duration (however long it
may
be). Whether this is acceptable is a question
for people with policy
setting power.
The point you're making may be too subtle for me.
Before:
a) Wikipedia had no way of displaying the locations of things on maps
b) Wikipedia had no way of providing extended book information based on an
ISBN
c) Wikipedia had no way of editing photos on the site
But it had workarounds:
a) You could manually go to some other site or an atlas and look up
the GPS coordinates
b) You could search google for that ISBN number
c) You could download the image, edit it and upload it again
Then we integrated (or are considering integration) with some third party:
a) You click a link and you see a map of the location
b) You click a link and see extended book information
c) You click a link and edit a photo before saving it back to Wikipedia
But if that third party site goes down:
a) You go back to the workaround, or use one of the other mapping services
b) You click a different link
c) You go back to the workaround.
Pretty similar. The real difference is actually that the map and ISBN
integration are tools for *readers*, whereas Picnik integration is a
tool for *editors*. Not sure if that difference is significant though.
So the objection so far seems to boil down to: It would be even better
if MediaWiki natively had this functionality. I agree. Is that a
reason not to make use of a third party site in the meantime? Are
there other objections?
Steve
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
http://lists.wikimedia.org/mailman/listinfo/wikitech-l