Supported community plugins "list" on Github

Destry · 2015-09-10 08:06:37

This is a spin-off conversation from here (unraveling multi-topic threads is tricky, so bear with me), where Maverick introduced an idea about installing plugins from Github.¹ In that thread he shared his personal MST – Textpattern resources list, which kuopassa threw in a handy plugin for that pulls from Mav’s list and generates a table-based output as a sub-panel under Extensions. All fun stuff.

But as the thread discussion goes on to show, Mav’s personal MST list (by evidence of Kuo’s attention drawn to it) might be a little confusing for those looking for an official Textpattern plugin list on Github. There’s also the fact Mav’s list is kind of a catch-all at the moment, if I’m not mistaken, including plugins and themes of any type/status — a collage of .org and textgarden. ;)

Which brings us to Pete’s effort for a Textpattern Community Plugins Repo on Github, which hasn’t gotten far, likely due to the more complex repo structure and greater effort needed to populate it. But the promise of it is its focus on supported plugins only that work with the latest stable release. (At least I think that’s the focus. If not, it should be, or why bother with the effort.)

Yet, obviously there’s a a barrier to supporting Pete’s repo, if just too much overhead. So, Pete, what if, in the meantime, we alter your TCPR to be more like Maverick’s, a simple list?… But with a focus on all supported plugins only. Then a version of Kuo’s plugin, or whatever, could be written for the new repo/list, if that would be useful.

The whole point is that it’s a more focused and official-type list focused on supported plugins, thus perhaps less confusing for people looking for plugins on Github, but is easier for people to contribute to (“Here’s my supported plugin link on Github, add it!”). Later, after it’s built up a bit and drawn attention, it might make sense to structure it more deeply and centrally, or whatever, if that really makes sense at that point. Maybe new ideas emerge by then.

Assuming that sounds reasonable, would it make sense to fork Maverick’s list as the TCPR list starting point and edit it down to supported plugins? (I’m not a Github jockey, so I don’t know.) Could the list be organized by plugin types, or topics of focus? Or is it better to just leave it alphabetical?

To be clear, I’m not pushing for action here. I’m just unpacking the convo that got entwined in the other thread. Now you have it.

Edit: Come to think of it, there should probably be two such lists: this one for plugins and another for supported themes. Or maybe the TCPR is divided in two for that purpose. Whatever. If nothing else, such curated lists of supported resources can be used later when/if any real repository is created, whether at .org or anywhere else.

¹ There ended up being two other conversations weaved into that thread’s topic. I’m just unraveling one. The other merged convo was about writing Dean Allen a final message about rights to the textpattern.com domain. If you’re compelled to talk about that further, please use a new thread, or some old one having better contextual fit.

Last edited by Destry (2015-09-10 08:16:00)

gaekwad · 2015-09-10 10:14:25

Destry wrote #294621:

Yet, obviously there’s a a barrier to supporting Pete’s repo, if just too much overhead. So, Pete, what if, in the meantime, we alter your TCPR to be more like Maverick’s, a simple list?… But with a focus on all supported plugins only. Then a version of Kuo’s plugin, or whatever, could be written for the new repo/list, if that would be useful.

Yep – thoughts here – for completeness, I made the repo, but it’s not mine, per se.

Destry · 2015-09-10 10:25:14

gaekwad wrote #294634:

I made the repo, but it’s not mine, per se.

That’s all I meant, you made it. Credit is generally attributed to the progenitor. It’s recognized that you created it for the “Textpattern Community”.

gaekwad wrote #294630:

Couple of thoughts on this:

i) throw up another repo under textpattern-community for supported plugins, name it something appropriate, give Rev Maverick the keys to build something amazing.
ii) fiddle around with textpattern-plugin-archive, call it something different, roll out some JSON goodness to gauge current supported version, etc etc
iii) something else I haven’t thought of.

Good ideas.

etc · 2015-09-10 11:52:24

As a disorganized plugin author, I often forget to sync between different versions on my site, .org, and Github now. Worse, I don’t remember which version is the latest one. This retains me from putting the code on Github. So +1 for storing exterior links too.

maverick · 2015-09-10 12:54:17

I am willing to help out with the project any way I can, when I can. However, due to work commitments, I’m going to be fairly booked over the next two months, and again in December. It will become more hit and miss.

Destry – you are correct about the hodgepodge. As the number of plugins have grown, I have been thinking of splitting the themes out under their organization and all the remaining non-plugins into their own organization. A bit clumsier for me, but it would help others. However, if a community version gets up and running, then I would leave my collection as is for now.

I prefer a more community effort at curation. No one person can successfully keep track of all the plugins coming and going on Github. Plus we all have day jobs and times of minimal activity.
I like the idea of forking repos for this project. If a plugin author takes down his Github account, we still have a copy available, and this allows the community to take over maintenance when needed.
I agree that we should handle themes separate from plugins. A best practice would likely handle Admin Themes separate from site themes – especially if there would be a browser/view plugin, but at this point, there really are not that many themes of either flavor on Github. Is it worth the small extra effort? Maybe.
I appreciate the idea of supported plugins only, but I don’t necessarily agree (I don’t necessarily oppose it either). I would still keep most all the plugins (except perhaps the incomplete experiments).
- There are plugins that are not supported by a particular version of Textpattern, but not everyone runs the latest version of Textpattern. They still look for plugins.
- Not every plugin is supported by the plugin author, or has been adopted by another maintainer. Even so, the plugin continues to work and may offer desirable functionality.
- A plugin may be abandoned and broken, but have a functionality that someone wants/needs. Github makes it easy for the community to help fix it. However, if we don’t keep track of it, it would fall out of sight/mind/use entirely.
- Going forward, we would likely end up w/ unsupported plugins. How accurate the list would be depends on how active the community is at maintaining the list. Realistically, I think if we advertised it as a supported list of plugins, we’d soon be guilty of false advertising.
I think Pete had the right idea at trying to standardize plugins
- Caveat: realizing not every plugin repo owner will comply.
- I would suggest we create some sort of meta data file. Among other information, this would offer:
  - Textpattern version compatibility information
  - Dependency if applicable, etc.
  - It could also indicate active support if desired. I appreciate Kuo’s info box where some of the plugins have “unsupported” in red, for example.
I appreciate etc’s comment about syncing, and external links. I don’t know if/how that might work.
- My original suggestion was not to push any plugin author to use Github, but to take advantage of the many plugins already there.
- Having watched Textpattern.org, and the forums over the years, I have come to the realization that some plugins will be listed on both, some one on or the other, and a surprising number only on the plugin author’s website, where few people know about them.

I suppose this is far more than enough to keep us discussing our goals as we move forward. :)

Last edited by maverick (2015-09-10 13:02:13)

maverick · 2015-09-10 13:59:43

I have opened a thread re: meta data and plugins.

It would be very helpful if there was an official way to determine if a plugin is compatible with X version of Textpattern.

gaekwad · 2015-09-10 14:37:49

maverick wrote #294663:

It would be very helpful if there was an official way to determine if a plugin is compatible with X version of Textpattern.

I think Stef was working on something along these lines for textpattern.org, though I am unsure of the current status.

maverick · 2015-09-10 16:05:00

gaekwad wrote #294672:

I think Stef was working on something along these lines for textpattern.org, though I am unsure of the current status.

I too thought I remember Stef working on that. I don’t know if this would help or hinder his efforts.

maverick · 2015-09-10 16:33:30

Brainstorming on how to organize this project (then I have to get back to my paying jobs :D)

I see three parts to this project:

The collection – being discussed in the thread
The plugin template and meta data scheme – being discussed in this thread
The implementation(s)
- kuo’s github Plugin and Theme Viewer/Browser
- Possible Future Upgrade for the Core’s Plugin Installer/Manager
- Textpattern.org
- Possible (optional) info source for the first post in a given Plugin support thread on the forum
- Other?

Question

Use the Textpattern Community organization, or create a second Textpattern Community just for Plugins?
- Pro of a second community – It allows us to focus that organization’s repos exclusively on plugins

How to use Teams?
- I’ve used teams as pseudo categories. We could do likewise.
- Better – use teams for the purpose of helping maintain community supported plugins

How to use Tags?
- As a Github newbie, I don’t know the proper etiquette for using tags
- I believe tags are often/usually used for versions/releases?
- Could/Should tags be used for other organization functions. Example Tags might include:
  - Textpattern Community Supported
  - Plugin Author Supported
  - Orphaned
  - Depricated
  - etc, etc.

Proposal

Categories of Plugins
- Official Textpattern Plugins
  - Created by/maintained by/supported by the Dev Team
  - Not in use, but availabe for future use if ever desired\
- Community Owned Plugins
  - High priority plugins
  - Ownership has been given /adopted as official plugins by the Txp Community
  - Maintenance and support is by the community
  - has their own plugin prefix (something like tcp_)
  - adopted plugins have had their prefixes changed to reflect Txp Community project status
- Open Community Plugins
  - Plugins that have been abandoned
  - Plugins that may be useful, but not top priority
  - The community has helped maintain, but do not guarantee
  - Not officially adopted by the community
- Plugins Maintained & Supported by their original author
  - actively supported
- Orphaned Plugins
  - Plugin author is inactive
  - may or may not work
- Deprecated Plugins
  - keep for historical purposes or old installs
  - functionality has been superseded by the core
  - functionality has been superseded by more recent plugins

Teams – if using teams for maintenance
- Dev Team
- Txp Community Team
- Open Community Team
- Orphan Team
- Plugin Author Team
- Depreciated Team

Responsibilities would vary for each team.

Devs and Txp Community Team would be for those actively maintaining the plugin repos assigned under their team.
Open Community could have anyone who requests on it.
Orphan and Depricated Teams would basically curate the repos assigned to them
Plugin Author – curate, pull in any updates
- We could add all plugin authors to this team so they could push/pull their own updates.

It may be a bit before I can check in, but push back and see what our collective minds can create :D

Bloke · 2015-09-10 19:10:47

maverick wrote #294687:

I remember Stef working on that. I don’t know if this would help or hinder his efforts.

Anything that gets the project moving in the right direction is a help! So please, carry on.

For reference, my slightly out-of-date thinking can be found there on Google Docs. Since that was written, Composer has pretty much become the de facto way to handle dependencies. So, as Jukka has done in his manifests and installer, you set Txp as a dependency of your plugin, and specify the version(s) the plugin works with.

Using Composer also simplifies upgrades as a single command reads the manifests, figures out which things need updating, resolves any dependencies, bundles up, downloads and installs everything. As in, all plugins at once if they all have manifests.

That doesn’t, however, help when the plugin becomes orphaned, as the manifest wouldn’t get updated, which is what the community Yes / No / Yes-If rating system I proposed tried to solve. For want of a better word, users of the plugin could “vote” on how well a plugin works with their particular version of Textpattern. And if it doesn’t quite work, the steps that can be taken to make it work could be documented and curated (think rss_admin_db_manager, which requires three lines of code to be added for everything >4.0.6, but otherwise still works to this day — though it could benefit from a little visual polish under Hive).

Thus, over time, the plan was that a central knowledge base would build up of all plugins that are compatible with every version of Txp, with an author or maintainer’s vote carrying the most weight. Whether that’s feasible or even desirable, I don’t know any more. Composer’s not my field of expertise so I don’t know how best it could be integrated.

maverick · 2015-09-10 20:01:37

Bloke wrote #294693:

That doesn’t, however, help when the plugin becomes orphaned, as the manifest wouldn’t get updated, which is what the community Yes / No / Yes-If rating system I proposed tried to solve.

Thinking aloud: is a rating system preferable, or in principle, any different, than having the community able to commit updates to a manifest? Or other meta data paradigm we might use?

Example: If each plugin is forked onto Github, and assigned to a team, then anyone on the team can push an updated manifest, or meta data showing whether a plugin is compatible.

I’ve thrown out some ideas to that end on this thread and Ruud has been added some useful perspective and suggestions.

I’m unclear about the Composer aspect, however. I see that several official Textpattern repos are set up to use it, along with Jukka’s plugins. Is Composer going to be an official part of Textpattern development going forward? If so, should we build off of it? Is it an something where we do both our current plugin format AND a Composer formate (they compliment each other), or we should pick either the the current format or the Composer?

maverick · 2015-09-10 20:23:34

An additional consideration:

We began this discussion re: Github hosted plugins. Textpattern.org is related, and what we do with the Github plugins can have an influence on Textpattern.org. However, Textpattern.org links to plugins hosting multiple places, as well as hosts some plugins itself.

What are the suggestions going forward? Encourage the use of Github? Upload a copy of every publicly available plugin on Textpattern.org to Github, even if the plugin author doesn’t personally use it? What is the appropriate and respectful etiquette in a situation like these?

For example,

a plug in is open source and available to the public,
but the plugin author doesn’t use Github.
I want to keep a copy of all the plugins I use in repos on my Github
- maybe I customize some of them.

Is it considered in good taste to upload copies?

If so, then those plugins are now publicly available on Github. If we fork those for the Txp Community collection, is that a problem?

Textpattern CMS

Textpattern CMS support forum

#1 2015-09-10 08:06:37