Community Plugin Development.

net-carver · 2008-01-05 06:45:29

All

It seems Stef has sparked some renewed interest in community plugin developments by picking up the long-dormant ied_plugin_composer and extending it in new and interesting ways. (The other prime example is zem_contact_reborn that is now in the very capable hands of Ruud.)

I’m posting this to act as a focal point to discuss…

if and …
how …

… such developments should proceed.

I have some ideas around the how side of things but would be particularly interested to hear what folks have to say about this. So over to you. I’ll chip in now and again too.

Last edited by net-carver (2008-01-05 06:59:48)

ruud · 2008-01-05 07:26:35

If the original plugin author doesn’t mind someone else taking over (as was the case with zem_contact_reborn) and the new plugin adds new functionality without breaking old functionality, I’d stick to using the same plugin/tag names and release a new version of the plugin. That’s probably easier for existing users of that plugin.

Same applies to authors that are missing in action and have not been active for a long time (more than a year or so). I’ve done a rewrite of sab_substr (which was no longer available for download) that has the exact same tag/attribute functionality.

In other cases, I’d release the plugin using your own plugin prefix (for the tag names as well) so both plugin versions can exist alongside each other without conflicting.
[Zem_contact_reborn did not follow that rule and its name is so similar to the original zem_contact plugin that many people don’t know they’re different plugins. Due to differences in attributes it wasn’t a drop in replacement either.]

What people should NOT do is release a community plugin without a 3-letter prefix.

net-carver · 2008-01-05 15:26:01

Ruud wrote:

What people should NOT do is release a community plugin without a 3-letter prefix.

How about community/collaborative efforts on new plugins as opposed to existing ones. Would it be worth reserving a ‘community’ prefix and putting it on the reserved prefixes page in Textbook? For example, com_ is an unused prefix at the moment.
Graeme and I hit an issue similar to this with the MLP Pack. We could have gone with sed_ or gbp_ or some funky mixture of our two sets of initials but we didn’t like gas (for Graeme And Steve) or sag (for Steve And Graeme)! In the end it was released in a non-standard way. Does anyone feel there should be a standard prefixing convention for collaborative (yet not fully ‘community’) developments?

Bloke · 2008-01-05 17:32:26

ruud wrote:

I’ve done a rewrite of sab_substr (which was no longer available for download) that has the exact same tag/attribute functionality.

And I, in turn, extended your version calling it the same name with a new version number because it was backwards compatible. Seemed appropriate at the time, glad it was the right thing to do!

In other cases, I’d release the plugin using your own plugin prefix

Makes sense if it’s a significant rewrite. With the plugin composer though, it would’t feel “right” to rebadge it with my prefix. It’s only about 5% my own code — and most of that was stolen off net-carver/zem’s templates! This one’s more of a spit and polish for 4.0.x at the moment.

A reserved com_ prefix is a good idea imo. It certainly works if a plugin is destined from the start to be a collaboration to avoid obscure/rude prefix amalgamations, or if all parties perhaps later decide the best way to go is to combine forces.

What I’m struggling with is what to do with the forum posts about old plugins that have been taken over or modified. Most people, rightly or wrongly, update the OP to always link to the latest version of the plugin (or to another site/post that contains said new version). If the author’s gone away that’s not possible so we are left with:

Add to the original thread at the end and hope people always start at the end and work backwards when searching the forums
Create a new thread and hope people don’t stumble upon the old one and download an old version or become frustrated over dead links

Is there some best practice for people to ask a moderator to either “retire” or archive a plugin thread and plainly mark the OP as “out of date” with a link to the new thread maintained by the new owner? Can we PM our already overworked moderators and ask? Or is there some better system?

Same goes for textpattern.org; as long as the original author doesn’t object and/or has been away for so long that the community agrees a new maintainer should be found, can rights of ownership be assigned to new maintainers? Having to create a new article about the same plugin bloats the list and is potentially confusing; not to mention that two plugin entries with the same name would also cause TXP to complain.

I think iblastoff volunteered to look at outdated plugin threads recently. Not sure how far he got before he was bitten by the plugin writing bug!

Last edited by Bloke (2008-01-05 17:37:24)

ruud · 2008-01-05 22:33:16

How about community/collaborative efforts on new plugins as opposed to existing ones.

I think most plugins are community efforts, even if there is just one developer. Plugins get better because of community feedback. It doesn’t really matter if the feedback comes in the form of code, documentation, feature requests, bug reports etc. Plugins are rarely 100% created by by one author without input from others.

Having a com_ prefix would create an artificial distinction between two types of plugins that are both community efforts, with a possible side-effect of making the com_ plugins get a better reputation than others (especially to new users); a sort of quality mark… That is not desirable, because quality of com_ plugins will likely vary a lot more than quality of plugins with the same author prefix. Also, the ‘quality mark’ issue will make it attractive for individual plugin authors to call their own plugin a community project (which, as I said before is true for most plugins to some extent)?

And I, in turn, extended your version calling it the same name with a new version number because it was backwards compatible. Seemed appropriate at the time, glad it was the right thing to do!

IMHO that’s not the right thing to do. If there is an active maintainer for a plugin, ask if you can take over maintenance of that plugin, otherwise there are two active maintainers for different branches of a plugin that carry the same name, which is confusing.

Is there some best practice for people to ask a moderator to either “retire” or archive a plugin thread and plainly mark the OP as “out of date” with a link to the new thread maintained by the new owner?

good idea.

Bloke · 2008-01-05 23:25:32

ruud wrote:

If there is an active maintainer for a plugin, ask if you can take over maintenance of that plugin

OK, sorry. I didn’t want to maintain it anyway, just added an extension I thought might be useful. I’ve pulled my version off the forum, no biggie.

hakjoon · 2008-01-06 00:23:40

Regarding updating forum threads so that they can point to newer versions that are not maintained by the original author I’d be happy to update threads to say that a new version has been released by a different author for something like Stef’s recent update to ied_plugin_composer which added to the original plugin.

If this is a way we want to go I’d be happy to make edits to the original posts with the new info.

Bloke · 2008-01-06 00:50:23

hakjoon wrote:

If this is a way we want to go I’d be happy to make edits to the original posts with the new info.

Cheers Patrick, that should help cut down on outdated information and potential confuse-a-thons (if only plugin authors like me would stop to think about common courtesy before posting an update in the first place *cough*)

What would be the best mechanism for this do you think? PMs are probably not such a smart move; maybe there should be a forum topic with a sticky note somewhere which moderators could subscribe to and people can post their plugin update from/to links? Guess it depends on the frequency this sort of thing occurs.

I’ve never moderated a forum so whatever works best and is least hassle for you guys, I’m happy with.

the_ghost · 2008-01-06 01:25:04

Why not to use wiki? Or some specialised solutions for common development? I think there nust be something easy for using. Forums’ collaboration seems to be not very efficient.

Mary · 2008-01-06 03:07:45

Re plugin threads: either send me an email or hit the ‘report’ button on the thread in question and leave a note. It’s simpler to just archive the old thread and let you create a new one.

I 100% agree with Ruud about not using a com prefix.

hakjoon · 2008-01-07 02:39:28

Wold we really want to archive the original thread? They often have a lot of good info. I guess we could always link to the archived version.

Textpattern CMS

Textpattern CMS support forum

#1 2008-01-05 06:45:29

Community Plugin Development.

#2 2008-01-05 07:26:35

Re: Community Plugin Development.

#3 2008-01-05 15:26:01

Re: Community Plugin Development.

#4 2008-01-05 17:32:26

Re: Community Plugin Development.

#5 2008-01-05 22:33:16

Re: Community Plugin Development.

#6 2008-01-05 23:25:32

Re: Community Plugin Development.

#7 2008-01-06 00:23:40

Re: Community Plugin Development.

#8 2008-01-06 00:50:23

Re: Community Plugin Development.

#9 2008-01-06 01:25:04

Re: Community Plugin Development.

#10 2008-01-06 03:07:45

Re: Community Plugin Development.

#11 2008-01-07 02:39:28

Re: Community Plugin Development.

Board footer