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@gmail.com wrote:
On 8/13/07, Jim Wilson wilson.jim.r@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@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l