Add 30 day hard deadline

[clayjohn]

This way we have a clear criteria for closing stale proposals.

30 days seems like a long time, but I want to ensure that a proposal is properly stale before it gets closed.

[fire]

This policy causes an autoclosing bot that cause people to spam on older issues to keep them active.

Is this something we want? It is very annoying to be in a proposal when people spam an active issue that has gaps but is very wanted.

[clayjohn]

This doesn't add a bot. We can use our discretion when closing issues. If there was a lot of talk but the issue just hasn't been accepted/rejected it can be left open. But we need a clear rule so that it doesn't feel personal when people have their issues closed. 120 proposals is already unmanageable and we don't have a clear policy for closing many of them.

[Calinou]

Suggested change

	5. If a post receives little or no engagement after 30 days it will be closed.
	5. If a proposal receives little or no engagement after 30 days, it will be closed.

Also, we might want to reword it to be able to close proposals that are actively commented, but mostly receive negative feedback. "Mostly" is subjective here, but when there are 5 different users who are against a proposal and only the proposal's poster remains in favor of it, it usually speaks for itself 🙂

[clayjohn]

I think there should be a separate rule for negative feedback. That way we can be very clear about which rule relates to closing the issue.

[vnen]

This policy causes an autoclosing bot that cause people to spam on older issues to keep them active.

Is this something we want? It is very annoying to be in a proposal when people spam an active issue that has gaps but is very wanted.

Even if we add a bot, we can close manually if there's no meaningful addition in the last 30 days and it's obvious when people are just spamming to keep it active. If people keep spamming after closing, we lock it.

[Xrayez]

Suggested change

	5. If a post receives little or no engagement after 30 days it will be closed.
	5. If a post receives little or no engagement after 90 days it will be closed.

I'm still not sure whether this place could be used for proposals with extended discussions. There are quite a bunch of proposals that really end up as discussions which were opened like 2 years ago but still updated recently, see here.

Also, you wouldn't really want to close godotengine/godot#14011 at all. 😛

[clayjohn]

That wouldn't be captured by this rule because there was engagement 18 hours ago.

Discussion is engagement. We are talking about posts that have received no comments for 30 full days.

Additionally they are closed at our discretion, if there has been. A lot of productive discussion then we can just leave it open.

[vnen]

Discussion can continue on a closed issue. Maybe we can add a rule to re-open closed issues if relevant discussion is active again.

[clayjohn]

@xrayex I didn't add your 90 day time limit, but I did add @vnen's rule about reopening closed proposals. whether the limit is 30 days or 90, there will be posts that slip through the cracks and get closed. Having a rule to reopen them should be enough to ensure that they get reopened.

[golddotasksquestions]

I think autoclosing is a very bad idea. Only because an arbitrary amount of time has passed does not mean the proposal is not valid any more. Why would I spend 3 hours, up to a day and sometimes even much more pondering over usecases, writing up a proposal, researching existing issues and feature requests, preparing mockups ect when in all likelyhood it was for absolutely nothing because it will get autoclosed.
The likeyhood for a contributor finding time and interest to implement a PR for my feature idea (not theirs) within 30 days is practically non existent. Even within a year I would feel enormously lucky.

[clayjohn]

The deadline is not 30 days for the PR to be implemented it's 30 days to have any engagement. If no one comments on your proposal in 30 days it's safe to say that no one else is interested.

We need some way of managing proposals, not every proposal is going to end up in the engine.

[golddotasksquestions]

The deadline is not 30 days for the PR to be implemented it's 30 days to have any engagement.

I understood that.

If no one comments on your proposal in 30 days it's safe to say that no one else is interested.

That's absolutely not true. Not everyone is browsing the proposal list regularly. Most people are busy using the engine, working on their projects, and will only come here if they are missing something, or if they have been pointed to a specific proposal or issue. There are plenty of issues on the main repo that get commented on months apart, sometimes even no comment and then suddenly a brave Samaritan comes by to submit a PR.
Who would care about engaging with an older proposal/issue if it is already closed?
It's the worst you can to for engagement.

Personally I would be more than fine it there were no new feature additions at all to Godot for 2 years, having the proposal repo closed completely and declared that only bug issues and issues about fixing of existing features is allowed.

But having a "Proposal" repo, asking them to adhere to a standard that requires substantial effort and commitment to submit, and then just auto close peoples proposals after X days because the first commentator did not make it in time, is pure asshole design.
And that's just besides the fact that this will lead to people making unsubstantial comments, to "save" a proposal, or other spamming behavior to circumvent the bot.

[LikeLakers2]

The deadline is not 30 days for the PR to be implemented it's 30 days to have any engagement. If no one comments on your proposal in 30 days it's safe to say that no one else is interested.

I would also have to disagree here, unfortunately. This tells me we are making the assumption that people will always know of a proposal and be willing to comment when they want it... which is simply not true. I don't believe we can seriously say "everybody knows about a proposal when it's made."

And as for being willing to comment when they want it, this flies in the face of some other rules I've seen being enforced on the godotengine/godot repo in the past. Specifically, we've been telling people for months (maybe even some years -- I'm not sure how long) that if they don't have anything to add to the discussion, they should just thumbs-up the original comment rather than make small comments like "I want this!"

So to suddenly require comments, that would end up causing people to make small comments like "I want this!" with no additional helpful content. Is that what we want now?

[clayjohn]

@golddotasksquestions I understand you are very sensitive on this topic. However, you are blowing things out of proportion and declaring that "the sky is falling" prematurely. If there are comments on a proposal it doesn't fall under this rule.

The rule says

If a proposal receives little or no engagement/discussion after 30 days, it will be closed.

It doesn't say "if there hasnt been a new post on a proposal in 30 days it will be closed". If it did, then your criticisms would be valid. This rule targets proposals that have had no engagement. Not posts that have had engagement but are currently not active.

@LikeLakers2 This is not godotengine/godot. This is a different repo with a different purpose. For a proposal to be valid it needs to be discussed among the community. No proposal is going to be perfect in its original form. It requires people to discuss and express how it will work in their game. godotengone/godot is for bug reports. If a bug exists, you don't need to keep spamming the issue.

[LikeLakers2]

This is not godotengine/godot. This is a different repo with a different purpose. For a proposal to be valid it needs to be discussed among the community. No proposal is going to be perfect in its original form. It requires people to discuss and express how it will work in their game. godotengone/godot is for bug reports. If a bug exists, you don't need to keep spamming the issue.

I think you misunderstood my point.

Previously, we had feature proposals within godotengine/godot, and within those types of issues, we would tend to enforce a rule that summarized to "If you want this but don't have anything to add to the discussion, don't comment, just thumbs-up the original comment." Being that this is still the godotengine organization, I would assume the same is being enforced here, to avoid unnecessary notifications.

Except now this seems to enforce that engagement has to be shown in support of the proposal, at least once every 30 days. So do reactions count as engagement? (We can check the time the reactions were made via the GitHub API, after all, so no worries about not knowing times) Or are we throwing that rule away in favor of "Comment if you want it, even if you have nothing constructive to add"?

[clayjohn]

@LikeLakers2 Please read my above comment. The GIP is a new process with its own set of rules. The rules that apply to godotengine/godot do not necessarily apply. It is vitally important for proposals to receive feedback and constructive criticism. So users are expected to engage with proposals and to iron them out together.

Again, so there is clarity, I did not misunderstand your point. The rules that applied to godotengine/godot do not necessarily apply to godot-proposals which has its own set of rules.

[LikeLakers2]

@clayjohn Don't worry, I read your comment. I read comments in full before replying.

If the rules that apply to godotengine/godot do not necessarily apply here, then we should be mentioning that too within the README, so that people will not be confused into thinking as such. Otherwise, of course people will assume that the rules that applied to feature requests on godotengine/godot will apply here too, as I have shown I believe.

And so long as people believe those rules to be enforced here, I believe my point stands: People will think that they should thumbs-up rather than comment if they have nothing to add, which in turn leads me to ask if reactions will count as engagement for the purposes of keeping the issue open.

[clayjohn]

Please see https://github.com/godotengine/godot-proposals#rules-for-submitting-a-proposal

This describes the rules for submitting a proposal.

[golddotasksquestions]

It doesn't say "if there hasnt been a new post on a proposal in 30 days it will be closed". If it did, then your criticisms would be valid. This rule targets proposals that have had no engagement. Not posts that have had engagement but are currently not active.

There are maybe 2 dozen users or less (most of them are core contributors) that come here so often and so regularly that they would not miss a new proposal.
There are a few hundred to a few thousand users who do not come here to check every new proposal within 30 days. By having this arbitrary short window to allow a proposal to be open, you completely shift the balance for what qualifies as an "engaging" proposal in favor of those few people who come here regularly.

[Feniks-Gaming]

This sounds like horrible idea. Rather than getting issues fixed we will play popularity contest. So what if my issue is not popular enough maybe today noone wants to touch it but it doesn't mean we should not be aware of a problem existing because eventually it will need fixing anyway.

[clayjohn]

@Feniks-Gaming you misunderstand the purpose of this repo. Issues go to the Godot repo. Godot-proposals is only for feature proposals.

Please don't burst into a PR calling it horrible without understanding the context.

Also as someone who fixed issues for others, I definitely am going to prioritize issues that affect more users. Im spending my free time doing free work for you. I want to prioritize my effort on things that help a lot of people and will be appreciated.

[golddotasksquestions]

@Feniks-Gaming is not completely wrong though. There are plenty of proposals that are not about completely new features, but issues with existing features. Issues that do not classify as bugs, but still need to be fixed imho.
Here are just a few of mine:
#167
#98
#128
#144
#151

[Toshiwoz]

Sometimes is just the tone, or way you express a feeling that led to an adverse answer.
The need for a role to decide when closing a proposal makes sense. The fear of someone spending time to put together a proposal that meets the standards and then seeing it closing after 30 days is also frustrating, and may lead to less proposals.
The latter might be a desired result, but may also lead to good ideas to be lost (not being posted or being closed).
Personally if I'd post a proposal, even if it will be closed, I'd be glad if there would be a way to re open it. Because for example, if someone else find it useful, and want to propose it, maybe with just a slight difference or addition, it would be a waste of time to re write it.

[golddotasksquestions]

@Toshiwoz There is nothing wrong with closing proposals for a number of reasons. Autoclosing them after X days if they don't have a comment is the problem we are discussing here.

[Feniks-Gaming]

"Also as someone who fixed issues for others, I definitely am going to prioritize issues that affect more users. Im spending my free time doing free work for you. I want to prioritize my effort on things that help a lot of people and will be appreciated."

Which is fine but current system doesn't prevent you from doing so. You are attempting to limit input from people who are not regulars here. If something is an issue it remains and issue regardless if it's a popular or unpopular issue.

You may not want to fix it but it allows opportunity to someone else to do it. I don't think hard limit is a solution. I don't have time to run social campaigns just to stop my issue from being deleted. There is zero support for your proposal in this very thread even.

[Xrayez]

I'd like to say that the idea of having a deadline may be more or less acceptable in a sense that it makes people who propose features to really prepare and to describe what they want from the engine, which can promote high-quality proposals.

On the other hand, a person who wants to propose something expects that his/her proposal will actually be reviewed by core devs in a timely manner accordingly.

Ideally, that means from the moment a proposal is made, I'd personally expect to receive feedback from people with enough authority such as the lead developer, the project manager, and of course anyone who has enough expertise and/or experience in a domain. That way, both the person proposing a feature and core devs reviewing them can express mutual respect regarding the time being spent at describing the use cases/proposal and the time spent reading and reviewing possible implementations by core devs, so it would be a win-win situation here. Without this, the process ends up playing a game of cat and mouse, hoping that a feature will be approved in the near future and/or feeling anxious that a proposal will be rejected, so yeah I'd personally like to avoid this torture and do it quick. 😹

The time goes on and people have their own plans for their projects and they may not allow to depend on a review process being unreliable, too:

• if a proposal is approved quickly enough, that means a person can focus on implementing the feature while still being "on fire"/"in the flow".
• if a proposal is rejected quickly enough, a person can accept limitations and do the necessary workarounds to the point of maintaining a fork for the sake of project's specific needs.

I want to clarify that this kind of workflow would only work for features which are completely new to the engine, hence my proposal about creating two separate templates: #39. This process also applies to people who can add features themselves. Enforcing deadlines on people who just request features and cannot implement them themselves isn't something that most people expect, hence the need for godot-ideas repo.

So as a Godot contributor, I'd want to have some kind of a superpower of summoning core developers when I need to, within the GIP process (discussing at IRC/Discord doesn't make it public, and I personally prefer discussions where I can think clearly). This kind of a magic spell should be used carefully as the amount of spell casts is limited to one per proposal. 🙂

Could the PR workflow be used to request high-priority proposals perhaps? Instead of creating an Issue you just create a dummy pull request. In fact if you're interested in high-quality proposals by the people who can implement features themselves, you can easily sort them out as it takes certain amount of skill to make a pull request compared to making an issue. Note that when I talk about making a PR, I'm not saying making a PR at godotengine/godot, but a textual proposal.

Having said that, there's still clearly two parties with largely different interests here depending on life situations and motivations: whether people have a busy life or do they have a lot of free time, whether they're being paid, even things like gaining/losing authority can be a big motivation/fear for some... But we all seem to have a common interest: improving Godot Engine.

[golddotasksquestions]

@Xrayez

So as a Godot contributor, I'd want to have some kind of a superpower of summoning core developers when I need to

Ideally, that means from the moment a proposal is made, I'd personally expect to receive feedback from people with enough authority such as the lead developer, the project manager, and of course anyone who has enough expertise and/or experience in a domain.

Would this not dramatically increase the pressure on core devs and reviewing contributors instead of elevating it (which was the purpose of the GIP as I understood it)?

I'd like to say that the idea of having a deadline may be more or less acceptable in a sense that it makes people who propose features to really prepare and to describe what they want from the engine, which can promote high-quality proposals.

I have to disagree here. It would just make me much less likely to speak up, even though there is a massive hurting stone in my shoe. An Autoclose based on time would result in having to go on a social media marketing campaign in order to get enough attention to the issue before it closes. Remember proposals don't just require the approval of core devs and contributors, but also an expressed interest from the community, see 4. of the rules:
Other users must express interest in your proposal for it to be considered. Godot is community-driven, if no other users are interested in your proposal, it may be closed

Some issues are more suitable for campaigns, other are much less so. Campaigning and social media is not everyone's cup of tee. If I don't want to go on campaigning, because I can't stand the social pressure, I just would not bother writing a proposal at all, even though the stone in my shoe hurts like hell with every step I make.

Also I feel like your proposed approach would exclude people who are not able or interested to submit PRs themselves from submitting quality proposals on how to improve the engine.

If you want faster response from core devs, contributors and community, to keep your fire alive, maybe it would be enough to label a Proposal as "ready for PR submission" so devs and contributors can sort them out and look at them first.

[Xrayez]

@golddotasksquestions your arguments are valid, and that's kinda my selling point, I'm mainly talking about those people who has previous experience/want to contribute to Godot development themselves while proposing features (me included). There seems to be a divide between these kind of people who simply request features and people who want to implement them themselves. As a contributor I want to alleviate the burden of "having to wait".

If I think that something cannot be implemented via modules/plugins at all that's where I'd use godot-proposals personally, because it doesn't matter how many people would actually find a feature useful (20%, 50%, or 90% of real-life projects being in development?) it's simply impossible to implement it without patching/forking Godot. I might be at the point of actually going this route to be honest (already do for some simple engine limitations in hard-coded constants), because neither my current ideology nor project's real-life needs are in alignment to Godot as I keep hearing "your use cases are too specific".

I did not have much experience in game development like 3 years ago when I first discovered Godot, and some people keep telling me that I should switch to some combination of game development frameworks instead where it's possible to have more control over development decisions without having to depend on potentially slow review process and/or fearing that a particular implementation is not suitable for Godot ideology. I guess that's just real life. But no I don't think I'll switch to anything else any time soon.

Sorry for rant. 🙂

[vnen]

If I think that something cannot be implemented via modules/plugins at all that's where I'd use godot-proposals personally, because it doesn't matter how many people would actually find a feature useful (20%, 50%, or 90% of real-life projects being in development?) it's simply impossible to implement it without patching/forking Godot.

Note that if something you need is impossible to do without patching Godot, the proposal can be about making that possible, so even if the end feature itself never makes to the engine you can still make a plugin.

I see the future of Godot (personally) to be about exposing interfaces so users can do anything with plugins (sometimes with GDNative), so the main engine is kept small but powerful.

[Xrayez]

I see the future of Godot (personally) [emphasis mine] to be about exposing interfaces so users can do anything with plugins (sometimes with GDNative), so the main engine is kept small but powerful.

@vnen yeah it seems like a lot of people don't seem to get the ideology behind Godot development, or in fact it may have changed recently or rapidly evolving. Are we aiming for something like what other commercial engines provide, or is Godot trying to become something akin to Linux kernel but in the field of the gamedev? 🙂

Actually I see no document which could formalize the development ideology of Godot. We have documentation on how to contribute (talk first, make sure that the feature is needed etc). There's even Godot's design philosophy but it doesn't really target the engine developers/contributors themselves, and has only introductory value. This is something which reduz can do I suppose, to avoid further collision of development ideologies.