Extensions Team updates and discussion (October 2021)

Hello everyone :wave: !
I wanted to discuss the current state of the extension team, and talk about our recent achievements and things I think are important to talk about.

Recent achievements

  • We now have 92 extensions! We are rapidly approaching the milestone of 100 extensions :partying_face:!

  • Some of the extensions begin to get really advanced! Check out the Dungeon Generator extension made by @tristanrhodes and @oscuridad666 :wink:

  • We have successfully converted 70 out of the 92 extensions to the new author format, using the GDevelop profile instead of a text field. The rest will be converted soon as the authors of the extensions register their GDevelop profile. Thanks to @Add00 and @arthuro555 for manually converting all of those extensions!

Current state of the extension team

The extension team is not exactly in its “golden age” currently.

  • @VegeTato wants to quit submitting extensions since they disagree with the open-source nature of the extension gallery.

  • Most of the members seem currently busy, resulting in fewer extension submissions and reviews.

That doesn’t mean we are not functional though! While there were fewer new extensions submissions, multiple extensions were updated and the pipeline of extension submission was improved, and we now have automatic checks on new extensions against the best practices :sunglasses:


I would like to start a discussion on the following points:

Structure of teams

I am just going to quote the last news post here:

To add more structure, I think we ideally would need clear rules to be discussed out carefully to get a good set of rules. Since that did not seem to be working in my past attempts though, I am going to try the RFC methods and post a set of rules and discuss those instead of trying everyone to come up with them together.

Here are a few rules I would suggest:

𝓣𝓱𝓮 𝓖𝓓𝓮𝓿𝓮𝓵𝓸𝓹 𝓣𝓮𝓪𝓶𝓼 𝓐𝓬𝓽

  1. A GDevelop team has 1 or more leaders and multiple members.

  2. A GDevelop team members have to be an actor in the development of the aspect that the team is focused on.

  3. A GDevelop team obtains a role on discord and a group + title on the forum assigned to them, so that they may be recognized as the ones in charge of a field of development in GDevelop and mentioned if attention from any/all of their members is needed.

  4. A GDevelop team leader has to be a well-known and trusted member of the community.

  5. A GDevelop team leader has extra permissions given to them to the resources linked to the resources, and to allow them to grant the discord role/forum group + title to new members.

  6. A GDevelop team leader is responsible for selectively giving out permissions, adding new members or removing some from the team, creating and managing subteams if they think it is useful and necessary, and organizing the team (getting multiple members not to work on the same thing, organizing meetings and discussions if necessary…).

  7. GDevelop team leaders are given free GDevelop Indie as a thank for their work + can gift 3 months of GDevelop indie to a member of the team once every 2 month (for rewarding for example a new extensions creator for his multiple new extensions submissions).

  8. GDevelop teams can only be created by @4ian.

  9. One can only be made a team leader by a team leader of the team in question or @4ian.

  10. A team leader can be destituted if more than 1/4 of the team is dissatisfied with them, or if they are doing anything very wrong like spreading hate, infecting GDevelop with potentially unwanted programs, harassment, abusing their permissions, etc.

  11. All teams get 2 channel on discord: an announcement channel where only team leaders can post to post updates, news, and announcements to the team and/or GDevelop users, and a public discussion channel, where the team or non-team members/normal develop users can talk about the topic the team is about.

  12. A team leader that is inactive for 2 weeks without prior notice will be destituted as a safety measure.

In the context of the extension team, the “advantages” one would get for being a leader is

  • Permission to push to master on GDevelopApp/GDevelop-extensions
  • Permission to select new members, and give them an “Extension Team” role/group/title
  • A special “Extension team leader” role/group/title

Currently, as far as I understand @tristanrhodes is the sole leader of the extension team. If you all agree, I would like to apply for joining the co-leadership of the team since

  • I am an experienced GDevelop extension developer my self too now
  • I have good git knowledge, allowing me to help manage efficiently the extensions repository
  • I am already trying my best to try and organize the GDevelop space, and I hope that getting an “official” position for that would make it easier for me to make things easier for everyone :slight_smile:

Extensions missing features list

I would like to put up a list of everything that is currently limiting us or could be improved in terms of extensions. Here is what I have so far:

  • No extension cross-dependencies
  • Private functions renaming (also another way of showing they are private would be nice since on small screen space/long function names they are overflowing out of view)
  • No accepting variables as argument
  • No using private functions from a private function
  • No colorful icons
  • No notification of availability of updates for extensions
  • No changelog in extensions

If you have anything more to add, please do :slight_smile: I will try to implement those, and we can notify the core development team about that list so that they may look into it as well.

Extensions for streamlinening processes across extensions

I want to ask a few questions about patterns in extensions. First of all, extensions abstract tasks for writing games, but should we try to use them to abstract tasks infro writing extensions too?

For example, the P2P, MQTT, and WebSocket extensions all have an “events queue”, which is internally an array with all incoming events, and it can be used either by a condition “event triggered” (checks if the array length is not 0), “mark current event as triggered” (removes element at index 0), “get event data” (returns the value at index 0), and it calls mark current event as triggered in onScenePostEvents.
Redoing this for every extension is like reinventing the wheel every time. Using a common extension for those queues would have multiple advantages:

  • The development of the extensions using such an events queue is simplified as prior work is reused
  • If a problem is spotted with the events queue, or a new feature needs to be added, the update is automatically made available to all extensions that use it, without needing to change the extensions individually
  • It gives a consistent way events queues work (for example, the different events queues in the different extensions may have some differences, like one could have the current event the last element in the array, the other the first element)
  • It gives the user a consistent way to use events queues, so that the experience is always the same independently of the extension, allowing to carry knowledge over

There is one huge disadvantage though, it is that an extension would not be self contained anymore. If one wants to use P2P for example, the don’t have to “just learn P2P” but also events queues. Of course, in practice, it takes as much learning as without splitting the functionality, but it gives off the impression of being more complicated.

This example is about events queues but it can apply to other domains too. For example, one could make a “binary” extension that stores binary data efficiently using javascript, that the user would not use directly but for example the firebase extension could download a binary image from firebase storage, store it into the binary extension and return an ID for the image to the user that they can give the sprite extension, which could exchange it with the data via the binary extension to set a sprite image to that downloaded image binary data.

What do you think of it? Should extensions rather be always self-contained or modularized like that?


That is all I wanted to share :slight_smile: If you want to add anything or discuss all of this, do not hesitate to do so :wink:



  1. The contribution process shouldn’t be affect or made longer. The process should always be Hey I want to contribute, what should I be aware of?, Ok thanks!
  2. The teams/works should always to open and approachable by anyone
  3. Everyone should have equal say in anything and the team leader’ opinion shouldn’t be divine
  4. Many contributors have made special workflows to improve and speed up thier contributions. These changes shouldn’t interfer with them
    5)I am worried if having this system will make contributors think it as a burden. Having a team leader is great, but they have things to do irl and this shouldn’t be a burden for them
  5. Adding to the 2nd point, contributors should be allowed to stop and restart contribution when ever they like. The system must be open and loose. Yes, it might reduce the amount of contributions, but in the long run, this seems logical to me

Yay! Go team! The 100th extension should be celebrated!

I like the idea. There are more contributions to the extension library every week and the amount is increasing. Having more people to look after it will always be great.

:laughing:. A page on the wiki called GDevelop team Act should be 100% made explaining the act

More reviewers

The extension team is heavily lacking on reviewers. I think a way to bring and encourage would be to have a Reviewing guide in the wiki. The last time I tried reviewing extensions, I was stopped by the 1) lack of knowledge with extension 2) Not having any proper guideline. I hope atleast this time the state of the team will be improved.

: )

1 Like

I must say that some extensions are added in less than a week :tada:

We are always in need of checker and anyone can be one, this is lately Davy provided us with an appreciable helping hand. Do like Davy, any help is welcome.

Extensions that take longer or that have not received a review do not find the a reviewer because the extension is too complex, any help is welcome.

There are also extensions that do not follow the best practices guide, in this case you should not be afraid to tell the author.
And other extensions where the author does not make the required changes.
Changes after a review must be made by the person who submits the extension or the person who submits the update.
Reviews are meant to train people, not to do things for them.
By training people in this way the quality of the extensions will be cleaner and require less review time for everyone

If an extension doesn’t see a change in the days following a review then it can be taken over by another person, otherwise the application will be closed until someone wants to take over or after a new zip file with the required changes.

The current goal is not to accept all the extensions, the goal is to have quality extensions thanks to the automatic verification process and also thanks to the best practices guide and the peer review.

All approved extensions are licensed under the MIT license, so anyone can contribute, if you don’t want other people to touch them we don’t have licenses for it. The software can’t block them, it’s also against the GDevelop philosophy to have proprietary resources.

I’m not answering to let the discussion happen but I’ve read the proposal/messages here and I’m happy to help/nominate new contributors/leaders to make things more “official” and help reviews be done in better conditions :slight_smile:

Since I have close to zero knowledge in code, I don’t have anything to add to the discussion; but the structure of the gdevelop teams act seems good. Even though is seems centralized, I believe in this case it’s a must. I’d like to both congratulate all of you guys for the work that has been put into GDevelop. Recently I’ve been using a lot of extensions, and boy…most of them are really really great and helpful. Thanks a lot! I hope this engine and its community keep growing and getting more attention!

I don’t want to deviate from the topic, but I’d like to ask: is there any social projects involving GDevelop right now? If not, is this something of GDevelop’s interest for the future? I mean, for exemple, a cooperative project with schools, involving teaching the basics and letting the kids/teens create their projects? Since GDevelop is such a great and intuitive tool, I see a lot of potential in this area.

I couldn’t login in at the time this was posted but commented on it in the discord but was a bad place for it because its easily skipped over with new msgs.

"I think it would make more sense for Davy and arthuro to be leading the extension team
[8:32 AM]
As both know how to use git and have been reviewing extensions on a regular basis and heavily work on extensions

ĘȵŢᶉỢҏϒ — Yesterday at 8:47 AM
Tristan has a passion for extensions and makes awesome ones and is very encouraging but as a team leader could be doing more than a cheerleader and more what is expected from the role of a team leader I’m not sure how many team leaders there could be but someone that knows how to use git and is reviewing extension ie (arthuro and Davey) would make great additional team leads"

Thanks @arthuro555 for posting this update and getting the discussion moving forward!

Ideally, GDevelop should have an executive team so that everything would not be dependant on one person. My initial idea is that team leaders automatically become members of the executive team, with @4ian as the leader of that team. Decisions would be based on a majority vote, with @4ian having the power to override decisions. (In the US, a 67% majority in Congress can override the President, but I don’t think that is necessary here.)

Removing a leader should be determined by a majority of the executive team.

I really like this idea. Having a dedicated space to have announcements and discussions for each team will help keep things organized.

We don’t want to get rid of our long-time leaders without good measure! 2 months is a better timeframe, which allows for life crisis, health issues, family problems, job changes, and other valid reasons.

I think the idea of multiple leaders is a good one. This will remove dependencies on a single person, and help keep the team moving forward at all times.

Regarding your application for leadership, I wholeheartedly welcome and endorse it! Your technical skills are well known, and your community interaction is level-headed, well-written, and reasonable.

Assuming I understand your question correctly, I like the idea of modular extensions. If there are common tasks that multiple extensions could benefit from, it makes sense to offer them separately. This will require GDevelop to manage extension dependencies (we have talked about this before).

Thank again, @arthuro555 ! I look forward and expect great things to come from this team. :slight_smile:

1 Like

One thing I want to say is if you can explain to idiotic guys like me, how to update the author of extensions is that I made 2 extensions but they don’t appear in my profile and then what I did is add myself as an author and resubmit the extensions to the same GitHub thread. I don’t know if it is the correct way to do it or not.
As you can see in the Extensions dropdown is 0 but I made 2

Agreed, we need to write a clear step by step easy to understand guide on every step of extensions making and submissions.

The goal of leaders is more to have people you can turn to if you have any problem, issues, require certain special permissions or if there are things you need to organize or discuss with other extension devs. It’s not a controller, more of a coordinator.
The goal of teams is not to give people responsibility and burden them with that, but to reward them of their contributions with more say in the future if GDevelop where they invested their time and efforts in and a clear badge/role to show everyone that they helped.

Ooooohhh nooo that was never my point at all! I don’t want ever to force people to work on anything! I am sorry if it came across as this. I never thought for a second that people should work on extensions for any other reason that they want to :slight_smile:


Ideally we would need a more serious name and to really think this more through, i just wrote some rules on the top of my mind in 30 minutes it shouldn’t become “GDevelops constitution” like that :laughing:

The extension best practices guide on the wiki is supposed to be a guideline for reviewing :wink:

Agreed, thanks Davy (if you are reading this)!

I wonder if we (extension team) should be offering some more resources on learning how to make extensions and review them, like online workshops on discord for example where we teach live to whoever wants to how to create or review extensions, or also making a step by step very complete example of a review of an extension, complete with screenshots, the discussion between the reviewer and the submitter, the extension file at the beginning, what the reviewer looks for, and what the extension looks after being finally approved by the reviewer.

I’m sure your input would be welcome as the core of GDevelop, we can’t take any decisions for GDevelop on your behalf :wink:

The extensions are actually made with event sheets, not with code. You can make some too as long as you know how to use GDevelop :slight_smile:

I’m very glad you enjoyed our work :slight_smile:

Not as far as I know, but you are welcome to organize one if you wish. I suggest getting in contact with 4ian if you have a clear plan/idea.

Big fan of that idea, though the only thing i am a bit scared of is that it might slow down the decision process for anything too much if we need to always cast votes… But if we find a good organization that should be fine! A big +1 from me for that and all followup proposition you made in that post about an executive team.

The idea I have of team leaders is basically the ones that have full administrative power over their workspace (for example, extension team leaders would have all the administration permissions for the extensions repository), and that this would therefore be a very dangerous thing when put in the wrong hands, therefore if there is any smallest doubt on a leader they should be demoted to normal members asap to prevent them from doing any harm. Ideally we should chose the leaders very carefully to prevent that but anything can happen and we need to be prepared for the worst imo.
In the case of unannounced innactivity, i do not mean that they should be demoted definitively, just until they come back to not leave dangerous permission unsupervised.
But then, I may be paranoid, and if you and other people think it’s better, I’d have nothing against doing it another way.

I am happy to hear your approval, thanks for your trust :blush:

What makes me uneasy with this is that if an user is expected to be interacting with multiple extensions through another one that it might come at the cost of end user experience.


I’ll update those soon for you, don’t worry :wink:


Ok, I began an explainer wiki page for the teams concept. Everyone feel free to contribute to it, change it, and discuss it!


(I have not yet written all ideas for teams I have yet, it misses on the top of my mind the language (translations, spellchecking…) and wiki (documentation of engine features and extensions) teams)

1 Like
  1. Maybe the example team should also manage the wiki too. And change the team name to documentation team. The examples are also in some ways documenting things. This team could also mange the question asked in the communities because in the set up suggested, answering questions is not included or assigned to anyone and contributors would start thinking it’s not what they are assigned for and someone else would do it. Someone should be regularly doing it. Depending on users answering other user’s is difficult. If the team is having a lot of task now, a seperate team could be created just for answer questions. It’s very important to help and make new users understand GDevelop, in the long run its going to help in everything (Better games made, new contributors, etc…) . I myself became active in the community because the questions I asked were always answered and it made it want to help others too

  2. Would the asset team leader have access to the server where the assets are stored? I think the assets should be stored where there is a system and open-ness (For members) of GitHub. As the assets can’t be stored on GitHub, some other place needs to be found

  3. I think the executive team includes the team leaders, but I suggest having the current core team members too as the team would be fresh and experienced members should always be there to guide everyone.

  4. ‘Work team’ could be renamed to ‘Project Team’ (PT). As it is a project specific team

  5. Soon we would need a ‘marketing/communication team’ which would take care of the profiles on different websites and advertise/spread the word of GDevelop

  6. I don’t get the API team, won’t the engine team take care of that?

Good luck with this whole teams situation, I was on the extension team and was ignored here and in the discord when I posted this If you want to have good retention in your teams you need to have good communication even if you disagree with the person you should at least reply back

I disagree, I find that contributing an example is waaaay different from contributing written documentation. One is about technical writing, the other is about using GDevelop in an effective way and showing the results you get doing so. The processes to make those kinds of contributions are very different and contributors to one very probably won’t contribute to to the other.

I agree about the importance, and thought it was obvious that all teams are partly responsible for that: teams are also meant as a group to contact if one needs help with something, for example if an extension user needs help using an extension, they can ask the extension team about it.
Generally, I think anyone and everyone can answer any questions as long as they have some minimal knowledge of GDevelop, and it doesn’t need extra perms or organization, so i don’t see any need for a team there.

I discussed those with 4ian and the GDevelop company prefers that we do not implement those concepts after all since they would add too much work for the little amount of contributors we are

That’d be something for the asset team leader to discuss with 4ian :wink:

You are free to add any team you think is necessary on the proposal, that’s why I posted it on the wiki :wink:

I am sorry you feel this way, I am not answering each sentence as that would be too spammy and time consuming. I had seen you propose Davy as a leader and asked them on discord how they would feel about it because of that. They seemed to say they were against becoming a leader. Since you were stating your opinion i did not think you were expecting an answer and i am sorry if you felt ignored because of my behavior.

1 Like

Seems like this conversation is becoming stale : ( Just wanted to let everyone know that you (Yes you, reading this) is part of this and you are welcome to contribute to this conversation and decision. Even if you just joined 2 months ago or haven’t contributed to GDevelop. Please do share your thoughts, it’ll be acknowledged and be known

: )

1 Like

I believe I did share some ideas for how a team could operate in an other topic few months ago, can’t remember which topic it was. But otherwise I think I have no place to get involved in this. The primary question is, who could be the leader. If you have a candidate then the leader should have some insights on this how to operate and should be able to discuss it with 4ian and the other reviewers. If you have no candidate for leading the team then it is going to be difficult to build any kind of structure.

Answering questions how to use an extension sounds too much responsibility for me. In case there is a problem and bug sure, extension team can respond and offer a work around, request a fix or even make the decision to remove an extension entirely if necessary. Answering how to questions in general should be not the responsibility of any team. This is what the community is here for.

Maybe, if there would be some paid support that we talked about regarding how to monetise GDevelop, maybe then the extension team could be required to answer some questions but only if the team get paid too but that would be a discussion for an other topic I guess, and again it is not my place to get involved in this.

1 Like

To be clear, teams are made of the community, and just like the rest of the community, they have no responsibilities over anything. At least the way I picture teams is more like a “sub-community”, that members of the main community can turn to if they want to get into extensions as well. That does not mean that members of a team are required to answer any question from anyone, just like everyone is not required to help others in the main community.

I see where you coming from but I’m not sure what do you mean, how exactly the community “can turn to” the extension team for help if they are not required to answer any question if they don’t want to. For example in the Cocos community the way it works if you have a very tricky, technical question then the community manager report your question to the dev team and then someone from the team get back to you and answer your question.

So I could imagine something like that but it would require to have someone dedicated to monitor the forum and discord for such tricky, technical questions. Just because the extension team is made of the community it is not necessarily means they are going to be active in the community.

I could imagine to also have some sort of “Community Support Team” with the role:

  1. Monitor the forum and answer GDevelop related questions in general, not necessarily “how to” questions but for example could point people in to the direction of tutorials, documentations, provide explanations how certain features works that sort of things…
  2. Submit bug reports on behalf of the community considering GDevelop welcome kids and non-technical people who may afraid to use GitHub so a CST member could act on their behalf.
  3. Contact the Development, Extension, Example team if technical information is required to answer a question just like in the Cocos community.
  4. Collect information what the community is missing the most and report to the teams say every 6 months the most requested, missing features.
  5. Post news, announcements
  6. May even fill moderator rolls.

So then just to be complete…

“Development Team”

  1. Development and maintenance of the core engine, IDE and build tools and services
  2. Review contributions to the core, IDE and build services
  3. When asked by CST, answer technical questions regarding the engine, IDE, build tools

“Examples Team”

  1. Review contributions to the examples
  2. Develop and maintain examples
  3. Submit bug reports for the Extension team and Dev team if an example is effected
  4. When asked by CST, answer technical questions regarding the examples

“Extension Team”

  1. Review contributions to the extensions
  2. Develop and maintain extensions
  3. Submit bug reports to the Dev team if an extension is effected
  4. When asked by CST, answer technical questions regarding the extensions

I realise the primary problem is that there is not enough people signing up and I honestly don’t know what can be done about that. Most people come to the forum because they are working on their own projects, they come to ask questions, may help fellow developers by answering some questions but signing up to contribute with anything to a project and the community is a completely different animal that means additional responsibilities. Even if you are trying to be nice and repeatedly say that, no obligations, nobody is forced to do anything, still it is makes no sense to sign up, agree and then do nothing walk away.

Signing up means you agree to certain responsibilities and most people don’t want that or just don’t have the time. I have no idea what can be done about that.

For now I think we should agree on a structure and how to operate, then you can spend more time thinking about how to find people to sign up and join.

1 Like

The teams thing is already a lost cause the team lead for extensions doesn’t have any responsibilities doesn’t have to review extensions doesn’t have to use git, All they have to do is say encouraging things on discord sometimes and release their own extensions, this whole team’s thing has been terrible it’s why I left being a contributor I used to do the asset store stuff and extensions, It doesn’t bode well for the teams that the first time someone that is in multiple teams brings up an issue with the team structure straight up gets ignored multiple times, Tristan not having to do anything is an actual issue so is the favoritism as his extensions get reviewed much faster and much more often than most, I thought not releasing my extensions for a period of time would help the process speed up for others but The order in which things are reviewed never got changed, the blatant biased and the red tape has just gotten worse with creating the teams


I am very sorry you feel ignored, but trust me, like I have said in my previous post (even if apparently i focused on the wrong point), I read everything and take your feedback into account as well for the proposal.

About your concern of teams not having responsibility, as you can read in the proposal:

As you can read, team leaders have responsibilities, and while the team members do not have explicit “responsibilities” as in they are not relied on and are not required to keep their field of contributions running, they still have some expectations they have to meet to stay in the team.
Regardless, the point of an extension team is not just giving responsibility, but also recognizing contributors for their contributions, and to give the permissions needed to the leaders for the team to be autonomous. Even if there was no responsibility involved, i think it would be worth it to add them just to have contributor’s work acknowledged.

To be clear, the proposal is still, well, a proposal, and not in an implemented state (hence why most teams don’t even have roles assigned yet and the team leaders do not have their additional permissions). There is not even a fixed list of who is in what team. As far as I know, the only thing that was decided member wise so far was that Tristan and me would lead the extensions team, it wasn’t clear to me that you or anyone else will be in any team. Allow me to repeat again, right now, teams are just a proposal. The whole point of it is to try and find a way to make contributing less terrible. Anything you are experiencing right now is still in a team-less state.

About Tristan not being a good fit for leadership, I think that while it is a good advantage to know git, it is not really need. To merge an extension, all one need to do is check if the PR is green (passes the automated checks), check if the extension is reviewed (or review it by yourself), check if no other file is added than the extension, and click on the “merge” button. No git knowledge needed :wink: As for fixing broken PRs, the goal for the extension team permissions wise is to ultimately have the team members possess push access to all of the repo (so anyone can modify any PR) except for master (the live repository) where only leaders can push. So any team member with git knowledge could fix a broken PR.

So with git excluded as a requirement for being an extension team leader, what other points remain? In my opinion:

  • Being someone you can entrust permissions to (access to the live extension repository)
  • Being someone who is likely to stay (no leader = no merge = no extension can be added to the repo :grimacing: ), so someone who said they wanted to quit (like you or VegeTato) are less likely to be chosen (no offense intended, it is your choice and normal to not participate to something you do not want to)
  • Being someone who had a lot of experience with extensions, proven by a lot of accepted submissions and/or good reviews.
  • Being active enough to have an overview of the team to make reports on its current state

Based on this criteria, I think that Tristan, as an active contributor that has proven himself to be trustworthy and submitted (I think) the most extensions, is someone suited for the role.

About your concern that there is no responsibility for leaders to review extensions, there indeed is not in the proposal, but i am afraid that if you voiced that concern about the extension team previously i have missed it. As i said before, the wiki page for the proposal is editable by anyone, you are free to add that or any other thing you deem necessary under the responsibilities of the extension team members or leaders :wink:
Right now, the proposal is lacking any per-team rules, only containing general rules for all teams. You can add a rule specific to the extension team, for example, “A team member has to review at least one extension per month”. Since one of the pillars of the teams concepts is acknowledging one’s contributions, I would rather not force too much if anything onto members though, since you should not do extra work imo to have your base contributions acknowledged.

About your concern of bias, the short answer is yes, and we can’t really do anything about it.
Following the principle of open source everything is mostly community based. As a result of that, extensions are reviewed by the community. We can’t really do anything against some community members investing their “free labor” into extensions they prefer :p. Generally, more complex extensions bill tend to take longer to get a reviewer, since, well, they are so complex many contributors just don’t trust themselves for reviewing it (for example the Isometric extension by Davy, I have no clue what his maths do and therefore cannot review it).
As for me, I generally try to treat all extensions equally as an answer to your previously stated concerns, though I am still mostly burnt out from reviewing extension day and night for almost my whole summer vacations to make you happy and lacking motivation due to you not recognizing that effort, so i have not reviewed much lately.

Again, if you think that is truly important, you can add it to the responsibilities of the extension team members or leaders, and if you are not satisfied with the pace of reviews contribute to it by doing some reviews by yourself as well (checking if an extension complies to a defined set of rules, with automations doing most of that work, and checking if the extension is usable is not that hard, you are more than qualified to do reviews)

I hope I managed to clear out most of your concerns. I have not, don’t hesitate tell us what you are still concerned with :slight_smile: We are all always open to hear your and anyone’s opinion.

Hey all,

Thanks all for your feedback, lot to read :sweat_smile:

I want to acknowledge that the current system is working far from perfectly (or in certain cases not working at all…), and this is because we’re evolving from a system based on the traditional open-source/GitHub way of doing things (which is basically: whoever has the time to do reviews do them on their own time) to something where we need more discipline and commitment (which is hard to find because we don’t have - yet? - full time people doing this).

What I suggest we do is:

  • Ensure we remove from the proposal any red tape or things too complicated. These teams should be composed of active members for which I give special privilege and trust on GitHub/other places so that they can progress without always having me/Bouh/existing collaborators to approve stuff. For this please comment or suggest edit to the wiki page that Arthuro started? Or suggest a new document?
  • We agree on some commitment from the team leaders about time/stuff they would do. Note that being a leader is not for life, it’s only when you want to do it and you can quit at anytime without prejudice of course!

What is important to understand is that we’re grateful for any effort made toward helping GDevelop. Teams should be there to allow more people to contribute.