Godot-proposals: There needs to be a better way to track what is being actively worked on

[EricEzaM]

As a preface, I am a pretty casual contributor so it's possible that this issue only applies to me, or contributors like me. However, I still think that this could be an important thing to think about since it lowers the barrier to entry for new contributors.

Describe the project you are working on:
Contributing to the Godot Engine.

Describe the problem or limitation you are having in your project:
I'll start with an anecdote:
I saw proposal #48 as well as issue https://github.com/godotengine/godot/issues/41083, and so I thought I might take a look at the curve editor to make some improvements to it. After a couple of hours working on it, a comment was made that someone was already working on an improved curve editor (for a couple of weeks already, it seems), so it was sort of wasteful for me to spend time on that in the first place. I cannot figure out how @Zylann knew that @WiggleWizard was working on an improved curve editor, at least from publicly available information and discussions. The comment in #48 doesn't really imply that he is working on it - it is just an additional feature request.

So I have run into this issue before too, where I may start looking at implementing a feature/fix but I later find out "oh, this is being rewritten by so and so.". As a result I sort of feel that I have wasted my time a bit.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
The first thing that pops into my mind is a public Trello style board (maybe Github Projects?) which allows users to openly discuss what they are actively working on. This way if I am looking to implement a proposal, I can go there and possibly see that someone is working on a rework/rewrite of that system and either a) move on, or b) see if I can help in any way.

Anyway, let me know what you think. Would this be appropriate? Have you experienced something similar?

Cheers

[WiggleWizard]

I can agree to this. It's also very confusing to know where to comment that you're actively working on something. Even in the proposal you mentioned it only proposes a single feature addition but I am working on an entirely new curve editor with many more features than just the one mentioned. I was torn between making a new proposal but also needed some GIFs and such to show the work in order to better form my proposal for the overhaul and just commenting on the exising proposal.

It would also be nice to lightly track progress so if someone drops an item, someone else can easily pick it up somewhere. It should also be a place to discover who you can collaborate with on certain items if it's a large piece of work. Perhaps linked to a Discord channel where others can discuss something before going into DMs (I'd prefer to avoid unsolicited DMs).

[Xrayez]

I think this situation is partly due to the fact that contributors themselves are not willing to announce that they started to work on something, because:

• they don't want to create any expectations that something will be done by them.
• they don't want to prevent other people to work on something just because they said so.
• they're not sure whether they're capable of implementing something in the first place
• they're not sure whether they can keep up (no motivation etc.)

I've stumbled upon this situation myself a couple of times already. I think the best thing you can do is searching through those issues and (especially) opened pull requests. You may also need to search through the closed issues/PRs as well because something might have been already rejected.

The first thing that pops into my mind is a public Trello style board (maybe Github Projects?) which allows users to openly discuss what they are actively working on.

They dropped Trello in favor of Godot Proposals and/or Godot Roadmap AFAIK. 😃

[Zireael07]

Godot roadmap seems to be very out of date, btw.

And I'll add "they're not sure whether they'll have enough free time to finish" to the list of reasons people don't announce having begun work on something.

[Xrayez]

After a couple of hours working on it, a comment was made that someone was already working on an improved curve editor (for a couple of weeks already, it seems), so it was sort of wasteful for me to spend time on that in the first place.

Sometimes it's not enough to know, because we have a tendency to forget, see example: godotengine/godot#24547 (commented years ago, only to provide a similar fix months after!). But as you see there, both enhancements had something uniquely useful even they targeted what seems to be the same limitation/issue, so it's not really a waste of time in my eyes, this certainly adds to your skill set once you've done something yourself.

[EricEzaM]

• they're not sure whether they're capable of implementing something in the first place
• they're not sure whether they can keep up (no motivation etc.)

These are probably the ones that most apply to me. Like I said, I am a casual contributor so a lot of the time I start working on something and I realise I just don't know enough about the codebase to figure it out, so I drop it. I wish there was more in code comments and documentation (I try to add it in my contributions), but that's a separate thing.

I also think it would be an organisational tool that would really be used by the core developers/contributors. For example, I know that the code editor and syntax highlighter is getting a rewrite by someone, and so features or bigger fixes/rewrites related to that area of the codebase should be held off until that completion, or at least the authors should be consulted before doing that. However, for a newbie coming in it may be difficult to find out that that is the case.

I don't really know what a solution to this would look like, but I think getting a discussion going here is a good start.

[TheDuriel]

Something that would already help a lot. Is if proposals could eventually be labeled as "accepted" and "rejected". This would not indicate whether or not it is something that is being worked on. But as a guide for people trying to find something to contribute. Telling them "yes, if you make this it will be worthwhile."

There is no point to making a proposal and discussing its value, if the actual decision comes down to "did someone make a PR for it?".

[clayjohn]

This is great feedback, thank you.

To my mind two broad solutions come up

Trello style board

As mentioned in the original post, we could implement a trello board (maybe using Github Projects?) for people to track what issues they are working on.

Pros:

• Easy to implement
• Looks nice

Cons:

• Potentially hard to maintain if casual users drop projects and disappear
• Adds another community space that needs to be managed by Akien
• Adds another resource for contributors to check before working on issues

Better Issue management policy

Building off what @TheDuriel said, we should consider implementing better policies around "accepting" proposals and using the assignment feature of Github. We assign bugs to more core contributors all the time. We do this because they are people who typically contribute a lot and are more likely going to fix critical bugs. However, I don't think anything is stopping us from assigning regular contributors to Issues/Proposals.

Accordingly, we can add some guidelines around issue management, asking contributors to clearly say that they are working on a particular issue/proposal, at which time someone from the bugsquad can assign the issue/proposal to that contributor

Pros:

• Adds little to the administrative burden
• keeps all information in one place

Cons:

• potentially hard to communicate (many contributors done read guidelines before contributing)

[Xrayez]

Something that would already help a lot. Is if proposals could eventually be labeled as "accepted" and "rejected". This would not indicate whether or not it is something that is being worked on. But as a guide for people trying to find something to contribute. Telling them "yes, if you make this it will be worthwhile."

I've also heard about a thing called "consensus" suggested by the project manager, it means that if most (core?) contributors find something "must-have", then even the decision of a lead developer to reject something won't stop a feature/bug fix to be implemented. That's only in theory though. But if you ask me, that's the definition of community-driven development, the way it's advertised on the first pages of Godot documentation, so I don't see why not:

Welcome to the official documentation of Godot Engine, the free and open source community-driven [emphasis mine] 2D and 3D game engine!

So, I think it may be one of the reasons why there's no accepted/rejected workflow yet, because there's no clear definition of who should be responsible for accepting or rejecting proposals... If the decision-making goes through a thin pipe, then that's quite ineffective. Just look at the number of opened PRs currently (yeah that's partly due to 4.0 compat breakage freeze, but still).

Of course the scope of accepted features should also be defined, that's why I've previously raised #575 proposal, which would allow to avoid the scope creep. 🙂

But I'm going off-topic here...

[Calinou]

PS: You can check the list of proposals with pull requests that will close specific proposals:

This feature was added to GitHub earlier this year.

[umarcor]

IMHO, GitHub provides enough features to cross-ref issues, PRs and comments (even across repos). Also, issues can be moved between repos. I believe this could be solved with guidelines and encouraging contributors to leave track of their efforts. However, as @Xrayez said, some contributors might not want to make it explicit, and that is legit too.