Some stats on Godot's growth on GitHub

[akien-mga]

Time is running fast and Godot's growth on GitHub (and in adoption overall) is as impressive as ever.

March 2019 saw the 3.1 release with our all time high score for the number of issues opened in that month, 776 issues!
Ever since 3.0-alpha, PRs have been incoming at a steady pace of ca. 300 PRs per month, with peaks at 444 and 441 PRs respectively just after 3.0-alpha and just before 3.0-stable.

As we just reached issue #30000, I quickly put together some stats to share here. If anyone wants to gather more stats from the GitHub search and/or API and make more interesting visualizations, please do! I'm always looking for interesting metrics to monitor the overall growth and health of the community of contributors.

---

Growth of issue/PR numbers

• Issue adding global doesn't automatically flush to engine.cfg and is confusing. #1: Feb 9, 2014. This is the issue with the most cross-references in GitHub as any issue mentioning "adding global doesn't automatically flush to engine.cfg and is confusing. #1" will link it (happens all the time when people paste backtraces without using proper code block formatting).
• Issue Pr-tween-fix #1000: Dec 19, 2014 (9 still open). Includes 308 PRs.
• Issue In node (Menu Button) is not running, the function (is_pressed ()) and in any case returns false ... #5000: Jun 2, 2016 (185 still open [+176]). Includes 1578 PRs [+1270].
• Issue ANN: Making the bug tracker use 5-digit identifiers #10000: Jul 31, 2017 - 3 years 172 days after first issue
  (596 still open [+411]). Includes 3511 PRs [+1933].
• Issue Validate engine command line arguments #20000: Jul 6, 2018 - 340 days after 10000th issue
  (1990 still open [+1394]). Includes 7183 PRs [+3672].
• Issue Some stats on Godot's growth on GitHub #30000: Jun 23, 2019 - 352 days after 20000th issue
  (4877 still open [+2887]). Includes 10803 PRs [+3620].

---

Here's a visualization of the number of issues created each month compared with the number of PRs created each month (same Y scale).

As we can see, alpha releases and stable releases always come with a surge in issues reported, as well as PRs opened, which is not surprising.
Testers are especially active around alpha releases to hunt bugs, and many new users come to the engine around stable release and find more issues or request new features.

The evolution of PRs seem to follow that of issues closely, though since ~3.0 there is a wider gap between issues and PRs -- but it's still amazing to get half as many code contributions as we get bug reports or feature requests.

I interpret the spectacular increase in the number of reported issues since 3.0 as a major increase in userbase, and thus a much broader testing coverage and use cases to fulfill, more than a sign that the engine would be more buggy than it used to be ;)

[akien-mga]

Source ODS and SVG for the above graph: GitHub Stats May 2019.zip

[Teashrock]

Will there be a code frezze or something? To close already existing bugs rather than implementing new features? It must be done sooner or later, or else the whole code will just collapse under it's own weight.

[KoBeWi]

I've been monitoring the issues in recent months and realized that fighting with them with the current number of active contributors is a lost cause. There's more of them pretty much every day. Soon, number of opened issues will reach 5k, and that's about 2 or 3 months after it was 4k. There's much more users, but not enough more contributors to do something about it. And "code freeze" is out of an option. It will make the engine stale and won't really help with decreasing issue number, unless lasts for like a half of year.

From some fun and vague stats, I've went through literally every issue recently. I didn't read it all, but I just browsed all the pages looking for something I could fix. Out of the 4969 issues right now, I have 642 bookmarked as something I could try to contribute. About 320+ issues could be closed by merging all existing PRs. Lots of the issues are invalid and lots are likely invalid and need testing (I still have almost 50 bookmarked issues to check).
Throwing some made-up percents, 40-60% are feature proposals. ~50% of bugs are platform- or device-specific or won't be fixed until Vulkan port is finished (and sometimes will be fixed by simply the port). There are also plenty of issues or proposals (let's say 20%) that require deep knowledge about the engine or rethinking of some its parts, so they can't be fixed by a random contributor.

Anyways, don't consider it a really reliable data, as I didn't measure it strictly. The point is that issues are pilling up and many of them can be fixed by more or less experienced contributors. The fact that they lay around for so long luckily goes along with them being not-so-much critical (we got many long-requested features for 3.2 already, and the rest is mostly random stuff that no one knows if it will actually be added). Godot's code is really friendly for contributing, so we should try to attract more contributors somehow. We have over 900 right now, but only a few % of them are actually active and the rest are pretty much one-timers.

[Calinou]

And "code freeze" is out of an option.

The engine does enter a partial code freeze phase during the beta/RC period. During this phase, only bug fixes can be merged, not new features.

[KoBeWi]

Ah, right. Still, it lasts too short and the freeze before 3.1 only slowed down the appearance of new issues.

[Toshiwoz]

Growth of user base is probably true. I wonder if there would be a way to also measure the amount of downloads from Godot Asset library to measure it.

About contributions, I would probably able to help more if I'd be able to DEBUG (sorry, I was distracted when I wrote this, I can already compile from VSC) in VS code, as visual studio is too heavy for my system. I am lucky that @willnationsdev helped me set it up to compile the editor, so at least I can test any code change I want.
But I couldn't yet set up the ide for debugging, adding documentation/tutorials for more ides might help have.more contributors maybe.

[KoBeWi]

About contributions, I would probably able to help more if I'd be able to compile in VS code, as visual studio is too heavy for my system.

Visual Studio is only required to build the engine (particularly, the command line build tools, not sure if it's possible to get them separately). I use VS Code for Godot contributing and with C++ extension it has all the auto-completion and IntelliSense (and probably debugging) you'd need. It's also easy to compile the engine using built-in terminal host, not to mention the integrated git tools with nice visual diffs, which really help.

[Houkime]

Visual Studio is only required to build the engine (particularly, the command line build tools, not sure if it's possible to get them separately). I use VS Code for Godot contributing and with C++ extension it has all the auto-completion and IntelliSense (and probably debugging) you'd need. It's also easy to compile the engine using built-in terminal host, not to mention the integrated git tools with nice visual diffs, which really help.

I am not really versed in Windows as i am Linux user, but shouldn't scons be able to build the engine as long as msvc/other win compiler is around without any IDE whatsoever?
Just from commandline like it does on Linux?

[Zireael07]

Seconding that, I'm sitting on a Linux box with VS Code currently and would like to hopefully take a stab at vehicle code again...

[KoBeWi]

I am not really versed in Windows as i am Linux user, but shouldn't scons be able to build the engine as long as msvc/other win compiler is around without any IDE whatsoever?

Yeah, if scons is properly configured (no idea how it works, just followed the docs), you can build normally from command line. You don't need any IDE. I was referring to VS Code (which isn't really an IDE) having a built-in command line, so you can compile from inside it. It's really convenient.

[lawnjelly]

Speaking as a new contributor I can see a few things which might be possibly improved:

1. Order issues by some kind of priority. There are so many that unless you are fixing something that you have searched for yourself, it is hard to separate the wheat from the chaff, so we can go for the low hanging fruit first.
2. It would be nice to have some kind of tree structure for the issues, rather than relying on labels. Labels are ok, but not as nice as a tree.
3. Possibly there's an argument (if there isn't already) for a forum for contributors only, to discuss issues / changes informally, help for new contributors, getting to know who is expert in which area, who is still active etc. Again maybe this is just another reflection of a need for a tree structure for areas of interest.
4. Looking at the PRs there can be quite a delay between submitting a PR and getting it looked at. I don't know if it can be improved, clearly there is a balance between letting contributors run riot and getting some decent peer review. Maybe there could be some more set reviewers for different areas.
5. You could also 'gamify' the bug fixing. Maybe by giving contributors points according to what they have fixed. Bit of fun competition. 😄

A lot of these may be limited by github though and what it supports.

[BenjaminNavarro]

I agree with lanwjelly, I'd like to start contributing to Godot but have no idea on how to pick an issue that I can fix

[Calinou]

@lawnjelly

1. Order issues by some kind of priority. There are so many that unless you are fixing something that you have searched for yourself, it is hard to separate the wheat from the chaff, so we can go for the low hanging fruit first.

In my experience, doing so is not very worthwhile in community-developed open source projects. People work on what they want to work on; we can't force them to contribute to specific topics if they don't want to. Low-hanging fruit issues are already labeled by junior job, though this label may not be 100% accurate as it's mostly based on developers' intuition.

2. It would be nice to have some kind of tree structure for the issues, rather than relying on labels. Labels are ok, but not as nice as a tree.

I'm afraid GitHub doesn't offer anything of the sort, probably in the interest of simplicity.

3. Possibly there's an argument (if there isn't already) for a forum for contributors only, to discuss issues / changes informally, help for new contributors, getting to know who is expert in which area, who is still active etc. Again maybe this is just another reflection of a need for a tree structure for areas of interest.

The #godotengine-devel IRC channel on freenode is probably what you're looking for. There's also an #engine channel on Discord, but most engine developers aren't very active there.

4. Looking at the PRs there can be quite a delay between submitting a PR and getting it looked at. I don't know if it can be improved, clearly there is a balance between letting contributors run riot and getting some decent peer review. Maybe there could be some more set reviewers for different areas.

The development team hosts regular PR review meetings, see #28853.

5. You could also 'gamify' the bug fixing. Maybe by giving contributors points according to what they have fixed. Bit of fun competition. 😄

The Contributors page and git shortlog -sn are probably the best we've got so far in this regard 😛

---

@BenjaminNavarro Take a look at the issues labeled junior job 🙂

[KoBeWi]

Actually, would be cool if there was some "contributor blog" where contributors could write about how they pinpointed and fixed various issues. There are many issues that could be junior job and they are fixable with just one line, but usually the problem is what line and where. Also, different people might have different approaches for finding the causes for bugs. Mine for example is Ctrl+Shift+F'ing for some known point (e.g. a menu item name related to the issue) and starting from there.

[BenjaminNavarro]

Thanks @Calinou for the tip. I started looking but it is not straightforward to see if an issue has a PR for it. Is there a way to sort out truly open issues?

[KoBeWi]

I started looking but it is not straightforward to see if an issue has a PR for it.

There is. Just look what issues/PRs referenced that issue. E.g. when you open #29814, you'll see

The green icon to the right is for PR, issue links are marked with

The Contributors page and git shortlog -sn are probably the best we've got so far in this regard 😛

Don't forget the "hall of fame" with top 100 contributors (I really like going there and watching as my position grows with each merge xd)

[akien-mga]

2 months later, I guess this can be closed :)