Scaling up the review of the community extensions

Hey all,

The number of community extensions is starting to grow! And this is great! :chart_with_upwards_trend:
For the next version, the search and the display of tags will be improved (using the same kind of interface as for the “Asset Store” - and the “Resource store” for the web app):

As more and more people start to get interested in making extensions (thank you!), a Trello board was made (thanks too, great idea!): Trello

I’m still unfortunately a bit of “bottleneck”, as I’m trying to review all extensions. This is to keep a high quality bar:

  • ensure the extension has a good reason to be there.
  • ensure the events are as simple as possible.
  • ensure the best practices are followed (use prefixed scene and global variable names).
  • ensure the description and names are well chosen, clearly explained. Ensure all sentences are correct, all parameters are shown, everything is following the same convention as existing actions/conditions/expressions.

This is taking a bit of time, so I’m wondering if you have ideas about how to speed up this? Should we set up some kind of “community review” of extensions? Maybe a checklist that anyone could follow to ensure that it will pass the “4ian review”? :smiley:

Let me know if you have ideas. Another one would be to make it easier to publish exensions, but have a list of curated extensions selected and pushed forward in the UI.

Overall, I’d really like to ensure extensions are growing faster without me being a blocking point (and at the same time, ensure extensions are “curated” and offer all a great experience to users).

4 Likes

What I’d suggest is to make “review teams”. For example, one team could review the javascript in extensions, another the grammar and spelling, another for the design of the API, etc.
Then, we could also have a github actions that looks for common things (prefixing the variable names with ExtensionName__, empty fields, unused parameter).

Passing all extensions through this should already make the extensions pretty clean, and faster to review as there would be less problems.

What I then would propose is having 2 more repos: a “unstable” extensions repository managed by the community: Extensions get merged with almost no review there (we only check if no other extension gets deleted, vandalized, or if the extension is not a troll/fake/malicious extension) for users to share their extensions for easily sharing the extensions with the review teams or with whoever wants to already start to test it.

Then, once an extension is judged stable by the review teams, it can be moved to the second new repository, the “lab” repository. This repository contains extensions that are judged stable to use but still need testing in the real world. GDevelop users could download it and start to use it, and once the extension has been used for some time, you (4ian) could make your own final review before moving it into the “core/main” repository.

Extensions in the main/core repository would show up as it does currently. Extensions from the lab repository could show up in the list if a toggle at the top right is activated. And finally, unstable extensions would need to be enabled in the IDE parameters.

All extensions from the lab repo would have a little “experiment vial” icon next to them, and unstable ones a warning icon to show the users that it is not a stable extension.

1 Like

I feel if there was more documentation on the wiki for best practices, naming conventions, etc. The quality of extensions will go up and it will be easier for new people to create extensions.

For example, this is the main page for explaining how to make extensions. However, it doesn’t talk about prefixing variables, or that functions should be named using PascalCase instead of camelCase.

So I think that if this were to happen extensions would be submitted with a higher quality and take less time to review. Since all of the best practises would be made very visible. New extension makers would learn the right practises from the start.

I agree. I think we can make a page with these best practice on the wiki and link it from:

  • the page about making extensions
  • GitHub
  • The GDevelop Extensions Trello.
2 Likes

I’ve started a page here: Extension Best Practices [GDevelop wiki]. I’ve made a link in the checklist that people must follow before submitting an extension.

Feel free to suggest new best practices or clarifications :slight_smile:

3 Likes

I thought that instructions were camelCase? If they aren’t, we should update lifetime functions to adopt those conventions.

Also I translated that page in french.

I thought that instructions were camelCase? If they aren’t, we should update lifetime functions to adopt those conventions.

All extensions internally are using PascalCase for expressions/actions/conditions. Lifetime functions are not because they were directly mapped to functions in the generated behavior class.

No big deal I would say.

Also I translated that page in french.

Thanks! :slight_smile: