Template talk:Incompatible/LQT Archive 1

I'm not sure I like the idea of pledging to fix the extension. It seems like it could lead to cookie licking, especially if the person pledging doesn't actually have commit access. Someone pledges to fix it, doesn't, but now that the pledge is made someone else who could have fixed the extension doesn't. That's not a result that we want. Reach Out to the Truth 05:28, 4 December 2011 (UTC)
 * Good point. What if there's a sort of countdown until their pledge expires?  My feeling is that will still be better than what seems to occur now with folks altogether nervous to update another developer's extension.  My hope is this will provide a way to help ease folks concerns, avoid the "I'm sure someone else will do it" phenomena that seems to plague some extensions, and increasing transparency.  Here's an example of a pledge with the built-in reset warning.  --Varnent 05:51, 4 December 2011 (UTC)
 * I should probably point out I'm "borrowing" this concept from Drupal - where I feel they've had a lot of success with it - especially in preparing for upcoming releases. Often times module (extensions) developers weren't aware their module wouldn't work with an upcoming release - this was a helpful way for beta testers to share that info and for developers to let folks know they were working on it - saving a lot of discussions and aimless searching on discussion pages.  This is designed to plug in future versions as well.  --Varnent 05:57, 4 December 2011 (UTC)
 * There is one big difference between MediaWiki and Drupal. Drupal does not use a continuous integration development model. So every new version of Drupal basically obsoletes all their modules written for a previous version. Thus if they do not have enough pledges to make a module compatible with a new version they might as well stop the entire show. Here at MediaWiki a new version does not necessarily break the extension. I think the lead developers here at MediaWiki even look into compatibility issues as long as the extensions are available in SVN. That is not a 100 percent guarantee but it seems to be a good bet to me. More coders should move their code to SVN as a matter of fact. Cheers --&#91;&#91;kgh&#93;&#93; 18:53, 5 December 2011 (UTC)