-
-
Notifications
You must be signed in to change notification settings - Fork 21.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some stats on Godot's growth on GitHub #30000
Comments
Source ODS and SVG for the above graph: GitHub Stats May 2019.zip |
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. |
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). 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. |
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. |
Ah, right. Still, it lasts too short and the freeze before 3.1 only slowed down the appearance of new issues. |
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. |
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? |
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... |
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. |
Speaking as a new contributor I can see a few things which might be possibly improved:
A lot of these may be limited by github though and what it supports. |
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 |
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
I'm afraid GitHub doesn't offer anything of the sort, probably in the interest of simplicity.
The
The development team hosts regular PR review meetings, see #28853.
The Contributors page and @BenjaminNavarro Take a look at the issues labeled |
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. |
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? |
There is. Just look what issues/PRs referenced that issue. E.g. when you open #29814, you'll see
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) |
2 months later, I guess this can be closed :) |
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
(596 still open [+411]). Includes 3511 PRs [+1933].
(1990 still open [+1394]). Includes 7183 PRs [+3672].
(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 ;)
The text was updated successfully, but these errors were encountered: