future of wp-cli-polylang

[diggy]

Hi,

I'd like to start a discussion about the future of this package with the people involved, some more than others: @dereckson @Chouby @nwoetzel @danielbachhuber

The WP-CLI package index contains an entry pointing to this repo, but the code hasn't been updated in quite a while. I recently submitted a PR to @nwoetzel 's fork (resolving issue #4 in this repo) as that fork was more up-to-date than the source.

We might start using Polylang frequently at work, and a decent CLI component is indispensable to make the plugin fit in our workflow. I recently spent some time on a serious rewrite of wp-cli-polylang, from the ground up actually, and currently at a loss on how to proceed, hence this thread.

Several options come to mind: I could release the package independently, and add a new entry to the package index. This is not desirable, as expressed by @danielbachhuber in a short conversation we had in the WP Slack #cli channel. See also this post.

I could submit a PR against the original package (this repo), but then @dereckson would have to agree with the overhaul, for starters. It could also break stuff for people depending on the package. Furthermore, for me, having to submit PRs and wait for merges all the time feels like inefficient and would seriously impede a healthy workflow.

Other options include giving me (and potentially others) push access to this repo (which might not be desirable), transferring the repo to me (if there is no time for or interest in maintaining the package), or transferring the repo to @Chouby (if interested), the author of the Polylang plugin, so the package can be maintained in the context of the Polylang organization here on Github.

Long story short, not really sure what to do :) Looking forward to your thoughts and opinions!

[dereckson]

Hey,

Welcome aboard Peter :)

TL;DR: totally willing to maintain wp-cli-polylang and to accept external
contributions.

First, there is apparently in priority a need to ensure the current code
base is in alignment with the current features of the extension. If I
understand your post, you have currently such code. If so, feel free to
submit it as a separate branch, so we can look there what it looks like.

Then, there is a need to solve pending matters. For example, I received a
pull request in 2014, immediately inquired but hasn't got any feedback from
WP-CLI maintainers on the best WP-CLI best practices applicable here:
https://twitter.com/Dereckson/status/501799371831513089. If you've an
advice to such level of verbosity, it so will be welcome. That would
benefit of a design guidelines document we can write after a brainstorming
on the subject.

Then, if we want to work together and accept external contributions, we
need a proper code review workflow.

Socially, something like "anyone can submit code ; nobody merge its own
code ; anyone can review and comment ; any regular developer of the project
can merge any code from another person" looks good to me. That will allow
to share knowledge on the project, to know what's going on and to ensure a
good quality. This model works pretty well on Wikimedia (my main open
source project where I'm a contributor).

I appreciate you stressed on the fact there is a need for a quick review
and merge process, so I'd advice when we work on the rewrite regular
communication and dedicated review windows where we can proceed.

Technically, I already maintain a CI infrastructure with a public instance
of Phabricator (allowing GitHub login) we can use for our wp-cli-polylang
project.

Following your message I created:

• https://devcentral.nasqueron.org/tag/wp-cli-polylang/ Project board
• http://devcentral.nasqueron.org/diffusion/WPCLIPOLY/ Repository just
  imported

So basically, right now, everybody on the planet can send code to review
through Phabricator
and we can have a proper review workflow.

Documentation is available at
https://agora.nasqueron.org/How_to_contribute_code

I'm going to add a CONTRIBUTE.md file to link to there resources and an
Arcanist configuration file.

We could accept pull request on GitHub from occasional users, but for the
core team, Phabricator offers a lot of additional benefits, all open source
aud under our control, like a kanban board, post commit audit in addition
to precommit review, comment are kept from one revision to another, etc.
Furthermore, this instance is already integrated with a Jenkins server and
notifications active on Freenode (we can fire to Slack too if there is some
activity there), al already configured for this instance. We're so totally
autonomous to work as we wish, independently of GitHub or any garden wall
requirements.

[nwoetzel]

I am glad to see that there is some movement coming to the project. With my little contributions in the past and potentially in the future, my opinion (and votes) should be considered with little weight.
Before moving to a different platform (from github to phabricator), these are the questions that come to my mind:

• is the project that complex that it cannot be worked on on github
• does this project not depend so much on the actual wp polylang plugin, that @Chouby should consider using something for contributing code to polylang first before improving collaboration on the wpcli-polylang-plugin

Considering these two aspects, I could definitely see a good future for the actual polylang plugin project if it would be hosted on github (or better phabricator) and the wp-cli-polylang would be fused into polylang. My experience at least was that I could not add some functionality to the plugin because there was no interface given by polylang - and it would have been so much easier to directly add code there...
I am not sure what @Chouby's interests are - but I think the polylang plugin could benefit from a good workflow of contributing code. Otherwise all efforts spent on wp-cli-polylang will be very dependent on @Chouby.
Since @diggy said, that there is a rewrite of the project, it might be a good point to fuse it into polylang and start from there to improve on the entire orchestration (e.g. polylang with wp-cli).

[danielbachhuber]

Hey all,

Just wanted to weigh in that I'm following along on this thread and happy to help out as needed.

Like I mentioned in my WCEU presentation and the Slack conversation with @diggy, I'd like for WP-CLI package maintenance to be considered a collaborative activity. I realize we have a bit to go to get from there to there, so I look forward to your input on what I can do as WP-CLI's maintainer to help facilitate this.

If you care about my two cents about workflow, I'd encourage you to use Github's issue backlog and pull request workflow for now, until additional complexity is merited. I've created a set of tools for scaffolding package tests and the README.md that you might consider using.

[diggy]

Waiting for @Chouby to chime in, here are my thoughts so far based on your remarks. I tend to agree that, for the time being, development should probably be limited to Github. I used the scaffold-package-command package to generate the boilerplate. I've had no real problems with the Polylang API as is, though I had to use the ReflectionMethod class here and there to access protected methods. I'm also not sure if the package should be incorporated in the PLL plugin, or be available as a separate package installable through WP-CLI. I don't know if one approach is preferable over the other, I'm sure @danielbachhuber could shed some light on this. Lastly, something to consider is the existence of a PLL Pro plugin, which I currently do not have at my disposal.

[danielbachhuber]

I'm also not sure if the package should be incorporated in the PLL plugin, or be available as a separate package installable through WP-CLI.

I don't have a strong preference one way or the other. Plugins sometimes package WP-CLI commands if the plugin developer thinks its something they want to build and maintain. In this case, I think it's perfectly reasonably that you guys maintain WP-CLI commands for Polylang, given you're interest in having them available.

[Chouby]

Hi all,

I am not using WP-CLI myself so I am certainly not the best person to maintain this project. So I would prefer that it stays in hands of other maintainer(s), and thus keep the development separate from Polylang.

If you believe that there would have some benefit to move the project to the Polylang organization, then that's no problem for me.

I've had no real problems with the Polylang API as is, though I had to use the ReflectionMethod class here and there to access protected methods.

If Polylang is causing some troubles, then feel free to open issues. I am open to ease your work :)
Pinging me as done here is also a good way to get me involved for some specific questions.

Pinging @shulard as he told me he had some interest in this project too.

[shulard]

Hello all !

Effectively I'm interested by the WP-CLI Polylang integration. I recently made a project where I needed a lot manipulating Polylang behaviour and I think it can help having some tools in the Command Line 😃

If you need a maintainer I think I can take the lead.

I don't have preference on a "right" place to put that code... Do you think it's better in the Polylang organisation or somewhere else ?

[shulard]

Hello Guys !

Any news about that thread ? After some reflection time, I think that keeping the two projects closer in the same organisation is a nice way to maintain them. It'll help to have a better communication between the developers and the same place for discussions.

Stéphane

[diggy]

Yes, I'm inclined to vote in favor of giving the CLI component a new home in the Polylang org. That said, it should probably be decided whether to replace the entry in the WP-CLI package index, or add a new one. Additionally, the class name, command $name (and potential aliases) and project slug (e.g. polylang/wp-cli-polylang, polylang/polylang-cli) should also be discussed.

[grappler]

I would be interested in contributing. I personally use Polylang and have it on a few clients sites. I have just written a batch translate command for media items as we had a media items not translated in the new languages that we added. Once the administrative things have been decided, let me know where I can make a PR.

[dereckson]

For the moment, please do here against this repository.

[danielbachhuber]

@diggy How'd this end up on your end?

[diggy]

@danielbachhuber I just released my package in the wild, you can find it here. Its current state is pre-alpha, there's a great deal of functionality already in place, currently missing are (more/better) commands to manage translations, nav menus, (country) flags, ... and tests ;)