Extensions and examples submissions

GDevelop general
1

Recently, we are beginning to get a lot of examples and extensions submissions. Many community members are dissatisfied with the current state of things though. Most of the complaints were on discord, so i decided to compile them here for more serious discussion about them. The most common points that are raised are the following:

  • Favoritism: extensions from GDevelop code contributors like me, Bouh and 4ian or extensions that look more interesting than others seem to get reviewed and added faster, and extensions that were submitted first left behind.

  • Lack of “advertisement”: some users said that they wished they had known earlier how easy it is to make extensions/examples and submit them.

  • Lack of reviewers: some users complained at how hard it would is to find someone to review their examples/extensions, making it impossible to go on with the submission process.

I think there is also another issue, linked to the above: the lack of clear structure. We recently said we would create community teams to handle extensions, the wiki, examples etc. But this was not done properly in my opinion: we ha e not decided what teams there are, who leads the teams except for the extension team, who can join a team and how, what can team members and the team leader do, what should they manage…

So the result is that everything is pretty much still fully managed by 4ian (he has to more or less review all of the extensions that are submitted himself). This makes the concept of teams pretty much useless.

So I am creating this topic to discuss and try to find solutions to those issues. I think first of all we should establish a set of clear standards for community submissions and the “teams”. They should cover:

  • What best practices/events code style we want and all can agree on.

  • What are the acceptable scopes of an extension/example (when an extension is abstracting too much, when it should actually be a built-in feature // when an extension is showing something too evident, when an example is showing how to do something that should rather be simplified via an extension/engine feature).

  • What teams we should have, who are in/can join the teams, what different roles the teams members have, and what permissions the different roles and responsibilities the different teams have.

  • What is the exact full process to submit an extension/example, from creating it to reviewing it to adding it to GDevelop (and everyone should respect the protocol to prevent favoritism).

Once we have a clear standard that makes everyone happy, we could then see how to make those more obvious. For example, if we want to have as requirement to becoming an example reviewer “Have been using GDevelop for at least 3 months and have used it actively for 48 hours in total”, we could then make a popup inside GDevelop encouraging users to become a reviewer once those conditions are met (this is just an example).

Pinging people that are concerned to bring the conversation forward

@Entropy404 @4ian @Bouh @tristanrhodes @VegeTato @Silver-Streak @Midhil

2

Don’t know how submission works and what is the hold up, do you guys having a chat about every single submission?
It doesn’t sound very effective if that is the case.
Instead I think each team member should review submissions in 3 phases and just leave a vote for each phase yes or no:

Phase1

  1. Not including any copyright material.
  2. Not malicious
  3. It is polished, no ugly bugs

Phase2

  1. Not a duplicate of an already existing example or extension.
  2. If it is a duplicate, is it offer any improvement? Better graphics, sounds, more optimal, practical logic.

Phase3

  1. Well documented, easy to follow
  2. It is useful and practical

If all 3 phases pass for everyone, then the team leader accept submission.

If Phase1 fail for anyone the team leader must deny the submission and explain to the contributor what need to change. Every team member 100% must be on board with Phase1.

If At least 70% of team members pass Phase2, team leader should accept it and in case there was any concern let the contributor know so he/she can improve it if choose to do so but it is not a must.

If at least 51% accept Phase3 , team leader should accept it and in case there was any concern let the contributor know so he/she can improve on it if choose to do so but it is not a must.

The team leader does NOT has the right to ignore the result of the votes, the role of the team leader is only to act on the votes and not to make decisions in 1 person.
The role of the team members is to review each submission and vote yes or no best to their knowledge and be able to provide an explanation if the team leader ask for one.

In case the team leader must deny a submission based on votes, people who did not accept it must be able to provide an explanation to the leader why exactly they did not accept it and the leader must explain to the contributor, what need to change and improve before can be accepted.

In case anyone STRONGLY disagree with the result, must provide an explanation to the team members and in case the general opinion of the team sill unchanged, ONLY then ask the team leader to contact 4ian to decide otherwise leave him alone and respect the result of the vote and either deny or accept.
The decision to respect the result of the vote or contact 4ian is up to the team leader.

Every 30 days or couple months, Team leader review the team members who is active and still mentally intact and remove inactive and crazy people from the team.

Every 30 days or couple months, team members review the team leader if still active and mentally intact and remove the leader if inactive or having a god complex. Team members or 4ian can point the new leader.

3

Agree that we’re “suffering from the success” of extensions (which is a great problem to have :smiley: ). There are too many examples/extensions submissions and we’re not super efficient at reviewing them all.

In the future, we might be less demanding on the quality of examples and extensions if we have a way to 1) submit them automatically on some kind of “marketplaces” and 2) have a way for users to rate them (so we could show in priority the “5 stars” extensions/templates).

For now, because the system is very simple, to ensure a very good quality for everything we review everything - and I’m the bottleneck in most cases. This leads to the problems you said.

What best practices/events code style we want and all can agree on.

What are the acceptable scopes of an extension/example

  • Especially important for extensions. Might be in the same “best practices” document?
    Basically, extensions should be more than a wrapper around a few actions/conditions (if that’s the case, better write an article on the wiki).
  • Examples could be either centered on demonstrating a specific feature OR be a full blown demo game (but must be very good quality). In both cases, it’s important to keep events as concise as possible. Clean and nice.
  • What is the exact full process to submit an extension/example, from creating it to reviewing it to adding it to GDevelop (and everyone should respect the protocol to prevent favoritism).

There are two things: it should be the same for everyone but we should also stay agile.
As an example, look at this bug fix. It was submitted, I looked at it, seen that it was good, merged it, done! We should have the “teams” responsible for moderating the submissions to be able to act quickly like this.

Basically:

  • New extension => full diligence and checks made
  • Update to an extension => if it’s an obvious fix, the “team leader” can go ahead and merge if someone else “approves”/verify the fix.

Don’t know how submission works and what is the hold up, do you guys having a chat about every single submission?

Currently, it’s indeed on a case by case basis. See for example a good example of a discussion here: Follow Multiple Objects With Camera · Issue #133 · GDevelopApp/GDevelop-extensions · GitHub

Note that we won’t avoid discussions. They are a good thing :slight_smile: But we need more people that review/vote/approve extensions so that me (and Bouh) are not the single “bottlenecks” in this process.

Instead I think each team member should review submissions in 3 phases and just leave a vote for each phase yes or no:

That’s a way to do it yeah.
I’m happy to implement this (or another “process”) as long as I can have people (“team leaders”) I trust for approving extensions :slight_smile: Ideally they would have git and basic command line knowledge to do the work of adding the extension (or the example) to the Git repository.

Just to restate it again: the main goal for now is to ensure all extensions and examples are of good quality. In the future, we’ll make them even more visible in the app, so we must ensure nobody is having a bad time by using a bad quality extension (lots of grammar mistakes/typos, hard to understand, not working on some platform, etc…).

I hope we can evolve the asset/extension/examples into a real “marketplace” for each of them, where we could have a team of moderators pushing the best into a “featured” section and a rating where everyone can vote. But this is a fairly important project by itself :slight_smile:

4

I think all of these ideas are great as far as what’s considered “good”, especially the phase review.

I had mentioned this a while back on the discord, but if people are looking for a process, this is basically what we had to do when I was a technical writer:

  1. Start from oldest first. If you are the person looking at the list, always pick up the oldest.
  2. Reviews/fixes for already created content (reviewing something someone already made, fixing something broken that’s out there) should always be addressed before requests for something to be built (barring exceptions)
  3. If you pull something that is too complex/you don’t have an idea how to solve, flag it as such and notify the group in some way, then move on to the next oldest. This way someone isn’t hammering away on something for days (which they may never be able to solve) when they could have gone through a bunch of other items during that time.
  4. Set up some sort of semi-regular cadence to get together to chat on those complex ones to see if someone can tackle it, or if people can tackle the issues together.

You will still need to define clearcut “what does good look like” checklists of some kind, but I think a lot of the conversation above establishes some of that already.

5

Even if there are not enough people you can trust to be a team leader, teams could still operate without one just to rate submission and give you an indication so you and Bouh can make the decision by having a quick look at the result.

Phase1 passed 100%
Phase2 passed at least 70%
Phase3 passed at least 51%

Then it is safe to add to the repo. I mean, you can expect higher % to accept but at least you would not need to look in to the details and just trust the team and let it go. I know it hard but there is no other way.

Team members could be any contributor, forum, discord moderator and forum members with leader rank maybe. Don’t know how many potential team member is that though, but if there was an easy, user friendly system to join a team and review submissions then maybe more people with the right rank would be interested to help.
There was a discussion on the forum recently about GDevelop account to link wiki, forum, GDevelop subscription, such system could be also one to add to the list of things you can access with a single account.

6

No (at least for the examples. Not sure about the extensions), it is just, if someone finds an open example\ that needs review, they review it. there is not much discussion between team member/contributors about an open example. The reviewer is responsible to handle it morally and review and request the needed changes. There is isn’t much a reviewer can follow in terms of guides. When the review process is complete (if the reviewer or the contributor mysteriously doesn’t abandon it), a member with write access adds the submission.

I think making each member review the submission can get a bit repetitive and can take a long time due to time zone issues, members being busy irl.

I had mentioned it earlier in discord about adding a bot for a basic review. A bot can be perfect to do the phase 1 (or phase 0). The bot checks for the basic and necessary things for a submission (Readme, thumbnail, description, etc…)

I suggest a slightly changed version:

  • Bot checks if basic things exist (Readme, thumbnail, description, etc…)
  • Reviewer checks if the submission is not a duplicate
  • Does some resource related/parameter check, non-code related stuff
  • Does a code review
  • Check for well written documentation
  • Checks if it is simple and easy to follow
  • Does a final check

If everything goes well, a submission could be added within a week*

Guide for the contributors:

  • The submission should concentrate in doing a single thing and develop from there.
  • The variables and timers should be named well
  • Try not to initialize variables in the events (?) (for the examples)
  • A size limit?
  • A readme should be added that gives a short description of what the submission is about
  • The events should be well documented with comments if needed
  • An icon/thumbnail should be added to the submission (64x64 size for thumbnails is preferred)
  • If the example is uses a lot of resources, they should be added to a “assets” folder
  • if the submission is too complicated/good for teaching, a wiki page for it can be created

Other things:

  • Automatically close stale submission
  • If a submission is not check by a reviewer within 2 week, the team leader should be notified

making submitting easier
One suggestion that I think might make reviewing, submitting, getting the submission popularity is to let the contributor submit the submission to the forum.

  • Most active members of the community have a forum account, which removes the hassle of making a github account, learning how to open issues

  • As a lot of people who have been using Gdevelop for years are here in the forum, there will be a lot more experienced people to review them

  • As many people are active here, the submissions that are being reviewed will get a lot more popularity

I am currently writing one for examples :slight_smile: I will wait until a proper structure is made from this discussion

:slight_smile:

7

That’s a good idea on paper, but right now we have trouble getting even one person to review all examples, i doubt having everyone looking into each one would be easy to achieve.

I meant more event sheet generally than content specific best practices. For example, is the common practice of putting a few empty events between chunks of events a good idea or should it be banned? Should we ask to always put (if the order is not necessary) free conditions before object conditions (as object conditions have their complexity multiplied by the amount of objects and can therefore cause performance loss)? Etc

I am wondering if we shouldn’t use githubs teams system for that. If the repos are on the GDevelopApp organization, you can set it up so that the master branch is protected (disallowing a leader to go rogue and destroy the repository), only allowing to merge PRs a member of the “team leader” team and if there are one or two approvals on the PR from a member of the “team member” team. If a PR gets ignored for too long one can mention the whole team at once asking them to review it.

I think that is a good workflow, fixes first, then new extensions, and from oldest to newest. Not sure if getting together for a chat would be easy though with all the different time zones and time of availability.

We already have this kind of “basic review” run by circle ci on extensions PRs I believe. That makes me think it would also be easier to review extensions if they were submitted as PRs, the issue is that this requires some git knowledge and can be demotivating. Maybe we can add an easy way to create the PR from GDevelop using octokit and isomorphic-git?

8

Won’t this add more bulk to the engine?

There can be a assets team, extension team, engine development team, documentation team, example team and also communication or a promotion team.

Or the teams could be divided into 3 the core engine development team, the supplementary team(takes care of things like extensions, example, game showcase, documentation, assets store) and the promotion team

Assets team:

  • Moderates the assets store
  • …

The documentation team:

  • Takes care of all the GDevelop documentation
  • Should be an user of GDevelop for more than 6 months

The promotion teams:

  • Takes care of the promotion part, all the GDevelop sites(?)
  • …

The engine development team:

  • Has multiple people with write access including the team leader (As there are a lot more PRs for the engine and having only one person that can push the changes might be slow)
  • Takes care of… the engine and it’s development
  • Should be an intermediate at atleast one of the languages GDevelop uses (JS, C++)
  • Should be familiar to the GDevelop engine (how to use it and how it works on the inside)
  • Should be familiar with git and github

The example/extension team:

  • Takes care of… the examples/extension library
  • Should be familiar with git and github
  • Should be an user of GDevelop for more than 6 months

becoming an member of a team:

  • The interested person could reach out to the team or the team leader, if the teams see if they are fit to be in the team.
    Or

  • If an user looks to be contributing/helping in the working/seems fit to a specific section, the teams members could ask the user if they are interested in being a part of the team

Rules

  • If a member is seen taking advantage of their powers in a harmful way, they will be removed/ their powers will be limited
  • If a member hasn’t contributed/been active for more than a year and a half without any info, A kind notice will be given asking for being inactive. If no reply is given in two weeks, they will be partially removed from the team (Their powers/ access to the repos will be removed)
  • No member (except the leader maybe) can push the PR to main without proper review from other members

Powers:
Common to all Team leaders

  • The team leader can control the access/ban of members and contributors.
  • If a big decision has to be made (Banning someone, removing someone from the team), it should be discussed with the staff and team members
  • The team leader can give extra access to people not in the team if needed

Common to all Team members

  • The members of all groups have write access to the trello board

The assets team:

  • All the members can have access to the tools and the place where the assets are stored(Doesn’t include write access) used by the team
  • The team leader can have write access to the place where the assets are stored

Example/extension teams:

  • Can close and control the submission and other workings of the repo
  • The leader has write access to the repo

Promotion team

  • All the members have access to the sites(Except the wiki) source code?
  • The leader has control of the sites
  • …

Engine development team

  • Team leader and people with write access can have write access to the repo
  • All the members can close, do most things except push commits

Documentation team:

  • All the members have partial access to the wiki (Create new pages, remove them(?), etc…)
  • The leader has permission to ban people, more access to the wiki settings

Other

  • The leaders and the members can be can be monitored and changed by the staff
  • …

This was just a rough sketch of how it cold be structured

:slight_smile: