Produnto has been deployed to the pilot wikis for two weeks and has had literally no usage in that time. If there continues to be no community interest in this extension, we can just undeploy it and cancel the project.

If you do want Produnto to exist, please migrate a few modules on mediawiki.org and provide feedback on your experience. Or if there is some missing feature that is preventing you from using it, please say what that is.

The strong issue existing is we need to be an admin to deploy packages. A second issue is access to GitLab is restricted and not many community members currently have (T436323: Automatically approve GitLab accounts for users with editinterface in any wiki).

And we have a competing proposed solution (T440142: Create templates wiki to hold global templates and documentation during development and testing). But treating modules as Wikipage is conceptually a worse idea. (more comment to come)

In T437970#12409414, @Bugreporter wrote:

The strong issue existing is we need to be an admin to deploy packages.

I think the simple solution is to just apply for it. You've got 977 edits to mediawiki.org going back 13 years and your block log is empty. If you want to move mw:Module:Yesno to Produnto, obviously that is going to need admin-equivalent rights because it's a fully protected page.

A second issue is access to GitLab is restricted and not many community members currently have (T436323: Automatically approve GitLab accounts for users with editinterface in any wiki).

There should be a button to request access on https://gitlab.wikimedia.org/groups/repos/lua/-/group_members . Two people clicked it and I promptly approved them.

I think the simple solution is to just apply for it.

But protected modules are just a tiny portion of all modules.

There should be a button to request access

The issue is not access to repos/lua (though I expect every users should be able to create repos there). The issue is because abusing by spammers, all new users in GitLab are by default blocked unless unblocked manually or automatically by a bot. Being blocked means they have no access to GitLab at all.

Note I just expect:

• everyone with access to GitLab can create repos at repos/lua
• repos at repos/lua can be written by owner (creator of repo by default), individuals invited by owners and owners (read: admin) of repos/lua or GitLab
• owners (read: admin) of repos/lua or GitLab can add new owners to existing repos

Of course, allow every GitLab user to push to every repos in repos/lua is a bad idea.

In T437970#12409656, @Bugreporter wrote:

The issue is not access to repos/lua (though I expect every users should be able to create repos there). The issue is because abusing by spammers, all new users in GitLab are by default blocked unless unblocked manually or automatically by a bot. Being blocked means they have no access to GitLab at all.

I'm just saying that you, as the person who has taken the most interest of any community member in this project, are hereby invited to test the extension by creating a GitLab account and deploying a package. If you have any difficulty doing that, please let me know so that I can fix it.

In T437970#12409620, @tstarling wrote:

There should be a button to request access on https://gitlab.wikimedia.org/groups/repos/lua/-/group_members . Two people clicked it and I promptly approved them.

There is no way to request access from that page. Instead, the option appears hidden inside the 3-dots dropdown menu in https://gitlab.wikimedia.org/repos/lua. It took me several minutes to locate it.

A step-by-step help page would help. I see Help:Extension:Produnto exists, but it skips mentioning how to your account accepted in gitlab, and how to request access to the group. I wonder what else is missing. I suggest using Claude to write docs. I no longer trust human-written docs because we are just so bad at it.

The help page also spends a non-insignficant amount of time talking about LuaRocks, which nobody on-wiki knows or cares about. Next, I install produnto-sandbox. I had node.js and npm already, but not everyone does JS development so this would be an extra step for them. Does it have to be in node.js? Consider rewriting it in a compiled language so that it can be installed as a flat binary. Now, configuring it seems like a huge chore. The command mentioned (produnto-sandbox configure) seems incomplete. The -i flag is required for it to prompt you for config stuff. The first prompt What is the wiki URL (e.g. www.mediawiki.org)? luckily has a default. I click enter. I get No response. Exiting. That's no good. Consider using commander for a richer cli where you don't have to re-enter the shown default. The next question is:

What is the OAuth consumer ID for the Produnto Sandbox CLI?
You should be able to find it in the approval log at
https://www.mediawiki.org/w/index.php?title=Special%3ALog&type=mwoauthconsumer&subtype=propose

This page complains There are problems with some of your input. Special:Log indeed doesn't seem to recognize type=mwoauthconsumer. I go to Special:OAuthListConsumers. I search for produnto. No results. produnto-sandbox. No results. Publisher=Tim Starling. Still nothing. Publisher=Tim Starling (WMF). There we are, Produnto Sandbox CLI [1.0]. I click details. It doesn't show a client id. Client id is only shown on Special:OAuthConsumerRegistration, which only lists consumers you created.

As an aside, the OAuth spec has a few new standards, DCR and CIMD, which help tools auto-register a OAuth client without having to prompt the user for a client id. But of course MediaWiki doesn't any of that.

Coming back to produnto, I realize Special:Log's type=mwoauthconsumer is supported but only on Meta. Cmd+F for produnto turns up nothing. Performer=Tim Starling (WMF) brings it up. Consumer key is 5c52418dbe7a51a59becd0625ac78cf1. I recall seeing such a string. Ah, it's mentioned on Help:Extension:Produnto! I didn't have to do all that digging. Silly me.

OAuth recently added support for first-party apps: T413288 / r1307846. Consider having the Produnto extension itself register the OAuth app with a stable consumer id that can be hardcoded into produnto-sandbox. This might require adding an extension attribute or hook to OAuth first.

Waiting for access to repos/lua before I continue. Overall, I'm sure Produnto would work great, but some investment in UX is required to break the barrier for entry.

I got access to repos/lua. I created https://gitlab.wikimedia.org/repos/lua/arguments for Module:Arguments. However pushing to it fails with (regardless of what branch name I use):

remote: GitLab: 
remote: You cannot push the initial commit because the default branch is
remote: protected and your role does not allow it.
remote: 
remote: To resolve this, either:
remote: - Ask a Maintainer to push the initial commit.
remote: - Contact an Owner or administrator for help.
remote: 
remote: Find a Maintainer, Owner, or administrator at:
remote: 
remote:   https://gitlab.wikimedia.org/repos/lua/arguments/-/project_members

In T437970#12419221, @SD0001 wrote:

I got access to repos/lua. I created https://gitlab.wikimedia.org/repos/lua/arguments for Module:Arguments. However pushing to it fails with (regardless of what branch name I use):

remote: GitLab: 
remote: You cannot push the initial commit because the default branch is
remote: protected and your role does not allow it.
remote: 
remote: To resolve this, either:
remote: - Ask a Maintainer to push the initial commit.
remote: - Contact an Owner or administrator for help.
remote: 
remote: Find a Maintainer, Owner, or administrator at:
remote: 
remote:   https://gitlab.wikimedia.org/repos/lua/arguments/-/project_members

See https://docs.gitlab.com/user/permissions/, so:

So:

• If default branch protection is enabled: Developer can create new repos, can develop in non-default branch, can make MR; but only Maintainer can merge MR (and thus apply change to default branch).
• If default branch protection is disabled: Developer can create new repos, can develop in any branches.
• Only GitLab admin and Owner of project or repos/lua can delete project.
• Newly created projects have no Developer and Owner by itself; projects always inherits Developer and Owner from repos/lua (whether the project have Developer / Owner or not) which can not be disabled.

This clearly segregate repos to two type: "protected" and "unprotected" repo. The ideal configuration is:

• All repos are "unprotected" by default (current repos are protected by default, needs change).
• High-risk repos can be "protected" by maintainers of project.
• There is a community process to elect/appoint maintainers and owners of both individual project and the whole repos/lua. (Maintainer can make or revoke Maintainers, but Owner can only be changed by existing Owner or GitLab admin.)

In T437970#12419221, @SD0001 wrote:

I got access to repos/lua. I created https://gitlab.wikimedia.org/repos/lua/arguments for Module:Arguments. However pushing to it fails with (regardless of what branch name I use):

For now I made you (and all other existing direct members) maintainers, and I opened up the default branch permissions to allow pushing by developers (as well as maintainers).

In T437970#12419240, @Bugreporter wrote:

The ideal configuration is:

• All repos are "unprotected" by default (current repos are protected by default, needs change).

Nobody needs to force-push to main, that's a footgun.

In T437970#12409385, @tstarling wrote:

Produnto has been deployed to the pilot wikis for two weeks and has had literally no usage in that time. If there continues to be no community interest in this extension, we can just undeploy it and cancel the project.

If you do want Produnto to exist, please migrate a few modules on mediawiki.org and provide feedback on your experience. Or if there is some missing feature that is preventing you from using it, please say what that is.

Excuse me for asking, but… who exactly are these "pilot wikis"? I do need to remind you that there aren’t many technical contributors. On frwiki, the contributors who work on Lua modules can be counted on fewer than two hands. Especially since the modules are all nearly +10 years old and support a wide variety of uses by communities with deeply ingrained habits. But I'm sure they could be convinced by this extension.

Is the test only on https://produnto-test.toolforge.org/?

It looks really interesting, but I think you might have more like a a difficulty in capturing the attention of those involved, than an "is this extension useful" problem.

For example, I can ask frwiki sysops to send a MassMessage to all the Lua editors active in the last year if needed. If found this extension by accident and it's already nearly shutdown...

In T437970#12419347, @Lofhi wrote:

In T437970#12409385, @tstarling wrote:

Produnto has been deployed to the pilot wikis for two weeks and has had literally no usage in that time. If there continues to be no community interest in this extension, we can just undeploy it and cancel the project.

If you do want Produnto to exist, please migrate a few modules on mediawiki.org and provide feedback on your experience. Or if there is some missing feature that is preventing you from using it, please say what that is.

Excuse me for asking, but… who exactly are these "pilot wikis"? And do I need to remind you that there aren’t many technical contributors at all? On frwiki, the contributors who work on Lua modules can be counted on fewer than two hands. Especially since the modules are all nearly +10 years old and support a wide variety of uses by communities with deeply ingrained habits.

Is the test only on https://produnto-test.toolforge.org/ ?

Currently Produnto is deployed on seven wikis: hiwiki, pawiki, orwiki, tewiki, mlwiki, testwiki and MediaWiki.org.

Thanks, I will share the message, since we can all try on testwiki.

I ported mediawiki.org's Module:Arguments to use https://gitlab.wikimedia.org/repos/lua/arguments. It worked smoothly enough.

In T437970#12409385, @tstarling wrote:

Or if there is some missing feature that is preventing you from using it, please say what that is.

• The elephant in the room is that packages can't be protected. The produnto-update right lets you update any package, even ones that may be used in fully protected templates. This means that the right can only be given to admins, or there would be a policy on using produnto only in unprotected templates, both of which are pretty self-defeating. (If restricted to admins, using it on less-used modules effectively makes them fully-protected – which is straight up against policy).
  • We should be able to give produnto-update to autoconfirmed users, and selectively disallow them from editing protected packages. All the protection levels as for regular pages should be supported for packages.
  • Opening it up to autoconfirmed users creates a vandalism risk. So there should be an easy way to undeploy a package or rollback it to the previous version from the package page. Ideally, there would also be a way to nominate them for deletion.
• The package namespaces pages are ghost pages that don't appear via search. This is confusing. The search index should be updated with packages - at least the page titles if not the content (so that they come up via autocomplete in the search box).
• Apart from that, a few more UX improvement suggestions:
  • There is a warning in previews that it used a local working copy and hence the page might look different when saved. Nice. But it can be made more specific. It can say what packages precisely were used from the local copy.
  • The header on top of package pages (https://www.mediawiki.org/wiki/Package:Arguments/src/arguments.lua) can link to the gitlab page where the original copy exists. If linking to the file is not feasible, link to the repo homepage.
  • For return require [[Package:...]] syntax, I see SyntaxHighlight doesn't create a link, while CodeMirror does it. SyntaxHighlight only links the require('...') form.
  • Very low priority, but it would be nice if package pages also showed up in Special:AllPages, Special:PrefixIndex, etc.

The package namespaces pages are ghost pages that don't appear via search.

See T91162#12419400. Note that comment may be updated further in the future.

I have started experimenting with Produnto by creating a simple package to manipulate Lua tables.

Is there any built-in way to unit test Produnto packages directly from GitLab’s CI? If no, there probably should be one. This would make packages more robust.

In T437970#12422858, @Danya wrote:

I have started experimenting with Produnto by creating a simple package to manipulate Lua tables.

Thanks!

Is there any built-in way to unit test Produnto packages directly from GitLab’s CI? If no, there probably should be one. This would make packages more robust.

No, because I don't know how to do that. And if I learnt how to do it then it would become my job to maintain it forever. There are plenty of engineers at WMF who could more easily handle it, but Produnto is not on their radar for whatever reason. I feel like user demand would help.

In T437970#12419642, @SD0001 wrote:

I ported mediawiki.org's Module:Arguments to use https://gitlab.wikimedia.org/repos/lua/arguments. It worked smoothly enough.

Thanks!

• The elephant in the room is that packages can't be protected. The produnto-update right lets you update any package, even ones that may be used in fully protected templates. This means that the right can only be given to admins, or there would be a policy on using produnto only in unprotected templates, both of which are pretty self-defeating. (If restricted to admins, using it on less-used modules effectively makes them fully-protected – which is straight up against policy).

I filed T440927 for this.

• The package namespaces pages are ghost pages that don't appear via search. This is confusing. The search index should be updated with packages - at least the page titles if not the content (so that they come up via autocomplete in the search box).

I filed T440935 for this.