Clarify that proposals should be issues, not pull requests

[Calinou]

People sometimes try to open pull requests for their proposals from time to time (like here).

[Xrayez]

On the other hand, this could be an alternative way to submit proposals for which an author is willing to implement him/herself. Currently, a lot of proposals in GIP are not actually proposals but requests or suggestions. "Merging" a proposal made via PR could be the missing link to approving proposals in GIP. We could also expand on this idea and create a roadmap document directly within GIP (just like current godot-roadmap), people could just append their proposal as being formalized.

That way, one could also prioritize which proposals can be actually implemented in a timely manner, and gives a better intention for both parties.

But that's just an idea.

[clayjohn]

@Xrayez I see the appeal of your idea. It would essentially "crystallize" the GIP once it was acceptable and create a way of tracking proposals that are accepted.

The downside is that it cuts users off from engaging with proposals once accepted, it limits changes to the proposal once accepted, and it creates a huge barrier of entry for users who are unfamiliar with Git. We already received pushback for using Github (because users would have to make an account), I'm not sure forcing everyone to learn Git would go over well.

For now, we should still with the current approach, and be clear about how it works.

[Xrayez]

The downside is that it cuts users off from engaging with proposals once accepted, it limits changes to the proposal once accepted

The pull request workflow doesn't really have to involve submitting changes as full-fledged proposal texts, that's not the point. You can edit the PR body text itself in a similar way without creating other PRs for that, just like for the issues. In fact, the diff could be as simple as the title of the proposal which might be eventually merged once the proposal is accepted, while still being able to engage in the discussion within the same PR, so that's not a problem in my eyes. In fact, merging is not even required, and could be postponed until the feature is actually implemented in the main repository, to prolong the visibility of the opened PR.

creates a huge barrier of entry for users who are unfamiliar with Git

The mere addition of an increasing number of guidelines or requirements (as added in #466, for instance), are the steps to increasing the complexity of the system to make sure that the quality of those proposals meet the expectations of core developers. If we go that route, might as well make a system which requires people to learn those tools, and you'll naturally filter out all the noise that you're not interested in moderating, and that's one of the motivations behind #154 for instance, you cannot deny that according to my previous discussion in GIP, but I might be wrong of course. 🙂

Of course when saying that, I'm talking from the perspective of a contributor who'd like to create proposals which I'm willing to implement myself, and as a way to talk to the core developers directly.

Note that I did not present my idea as a replacement for the current process, but as an alternative to the existing workflow, for possibly more advanced users who don't just request or suggest ideas in GIP, which takes more space than actual proposals here in GIP currently, that's all.

[Xrayez]

Approving pull requests would be a way to give a formal approval to proposals as a core developer, and you don't even have to be a Godot member or have any kind of privilege to do this. 🙂

[aaronfranke]

@Xrayez An approval system can also be achieved with a label, like we already have "topic:core", we could add "approved" or "planned" labels or something. But this is something to discuss with @akien-mga first.

[Xrayez]

Yeah, but one has to be in the bugsquad team as a minimum requirement in order to be able to assign labels like that, and the approval would mostly boil down to further discussion on IRC #godotengine-meeting channel before such a label can be assigned, and would be assigned by Akien most of the time. The idea behind PR approval is exactly the freedom to formally express approval (as a core developer or an outside contributor), without having those rights. I'm saying this because the number of 👍s doesn't really mean anything to some of the core developers in Godot, but I hope that would still play some role in the decision making process, even if, as someone noted, the decision making is not based on democracy, but at least based on meritocracy or do-ocracy of developers.

[clayjohn]

The mere addition of an increasing number of guidelines or requirements (as added in #466, for instance), are the steps to increasing the complexity of the system to make sure that the quality of those proposals meet the expectations of core developers. If we go that route, might as well make a system which requires people to learn those tools, and you'll naturally filter out all the noise that you're not interested in moderating

There is a huge difference between making rules to increase the quality of proposals, and creating arbitrary barriers to submitting proposals. We don't want to push someone away because they are uncomfortable with Git. We do, however, want to ensure that every proposal is thoughtful. I hope you can appreciate that difference.

[Xrayez]

No, I totally understand the difference, I certainly don't want to create arbitrary barriers for the sake of it, mind you. But when you say #39 (comment):

You have to understand the amount of work that core contributors (who are volunteers) have to put in right now in moderating random feature proposals.

It makes me think that on some level, one of the motivations behind those rules is to decrease maintenance burden. While creating rules and guidelines could certainly increase the quality of proposals (as you said!), I feel like a lot of people will simply choose not to read through guidelines and fill out those templates and just close the tab, which could be seen as a barrier to some, but nonetheless makes the work of core contributors "a breeze". 😛

I mean, the formula is: more rules → less people → less proposals → easier to moderate.
But the following also holds true: more rules → less proposals → more high quality proposals.

Or do you actually think that the formula is: more rules → more (or the same) people → less proposals → easier to moderate? It won't work like that, in my opinion.

We don't want to push someone away because they are uncomfortable with Git. We do, however, want to ensure that every proposal is thoughtful. I hope you can appreciate that difference.

Again, that's another instance of "To have a cake and eat it too".

The PR workflow simply ensures that a person would be capable enough to create a high quality proposal, because if you do know Git, then what are the odds of a proposal to become high-quality and technically viable?

It just depends on what you want to achieve really (is GIP a place for user suggestions as well now?), there's always some trade-offs to be made of course.

#39 (comment):

I'd also like to point out that the main repo has 1000 feature proposals and 1500 proposed enhancements. That number is extreme, most of those will never be implemented and so they have no value for anyone. If a person makes a feature request and absolutely no one else expresses interest in that feature, then it should not be implemented. This new process gives us the tools and procedure to properly close unwanted feature requests.

#47 (comment):

Godot isn't suffering from a lack of half-baked ideas right now, in fact, we are drowning in them. We have no clear way of distinguishing good from bad ideas right now. Godot-proposals solves that problem, it cuts off half-baked ideas at the source. This proposal seeks to bring back all the low-quality proposals for same ill-defined gain.

Just saying that, even with the current system, GIP has accumulated over a 1000 proposals in just a year (most of them do not properly answer the "Describe the project you're working on" question, and none of those are closed, being nice-to-have rather than need-to-have), so that's why a PR workflow idea came to mind, I do not suggest to actually make it happen, but then again what are the priorities? I'd personally keep the current system but make it less dichotomic and reflect the community needs rather than focusing on the fearful maintenance burden, I don't know, "choose your poison" as they say in English. 🙂

[aaronfranke]

I think what you're really asking for is if we somehow had PR reviews available on issues, so that people could leave a check mark on proposals. I don't think this is worth switching proposals to be PRs over. The closest thing we have that is built into GitHub is emoji reactions, and I think these work fine.

[Xrayez]

One minor nuance regarding emoji usage vs approval marks is that emojis do not track the timeline (unless there's some hidden GitHub API access for that). The proposal text could be modified any time so this could prevent those kind of approval hacks (modify the proposal slightly after approval was made, for instance), but that's far fetched indeed. 😛