www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.internals - Drive-by feature pull requests

reply Nick Treleaven <nick geany.org> writes:
Recently there have been a number of pull requests that add a 
significant feature to D, with no previous design discussion. I'm 
talking about features that quite clearly need a DIP. Some of 
these did then get a forum DIP post. But then you have some 
design discussion in the PR and some on the forum, and it's 
harder to track which feedback has been addressed by the 
submitter.

This is also undesirable because pull requests should mainly be 
about reviewing the implementation. Pull request comments are not 
properly threaded and are harder to follow, and they get in the 
way of implementation discussion and reviewing. Design discussion 
should happen primarily on the forum, or in other places than a 
PR.

How can we stop this? When anyone sees this happen and there is 
no disclaimer in the PR, anyone should add a warning not to 
critique the design in the PR and to open a forum thread instead. 
Possibly a threat to delete subsequent design discussion if the 
warning is ignored may be useful. This still relies on the 
warning being given soon after the PR is submitted. But it could 
help inform people not to do this.
Oct 14
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 14/10/2026 10:48 PM, Nick Treleaven wrote:
 Recently there have been a number of pull requests that add a 
 significant feature to D, with no previous design discussion. I'm 
 talking about features that quite clearly need a DIP. Some of these did 
 then get a forum DIP post. But then you have some design discussion in 
 the PR and some on the forum, and it's harder to track which feedback 
 has been addressed by the submitter.
 
 This is also undesirable because pull requests should mainly be about 
 reviewing the implementation. Pull request comments are not properly 
 threaded and are harder to follow, and they get in the way of 
 implementation discussion and reviewing. Design discussion should happen 
 primarily on the forum, or in other places than a PR.
 
 How can we stop this? When anyone sees this happen and there is no 
 disclaimer in the PR, anyone should add a warning not to critique the 
 design in the PR and to open a forum thread instead. Possibly a threat 
 to delete subsequent design discussion if the warning is ignored may be 
 useful. This still relies on the warning being given soon after the PR 
 is submitted. But it could help inform people not to do this.
Why stop it? People need to be able to determine if their ideas are even implementable before putting in the work of anything DIP related. And sometimes other people are able to spot problems at this level. It may be annoying but its part of OSS.
Oct 14
parent reply Nick Treleaven <nick geany.org> writes:
On Wednesday, 14 October 2026 at 21:33:45 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
 Why stop it?

 People need to be able to determine if their ideas are even 
 implementable before putting in the work of anything DIP 
 related.

 And sometimes other people are able to spot problems at this 
 level.
Yes, I'm not objecting to that. I'm objecting to significant feature design discussions in a pull request. If a PR needs implementation scrutiny or needs CI testing, fine, submit a PR. But it would be good to remind people in the top PR description not to critique the feature design, and link to a DIP ideas thread so that they have somewhere to vent their feature design comments. The DIP ideas forum does not need a full technical DIP document, it just needs to communicate the core ideas.
Oct 16
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 16/10/2026 11:17 PM, Nick Treleaven wrote:
 On Wednesday, 14 October 2026 at 21:33:45 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:
 Why stop it?

 People need to be able to determine if their ideas are even 
 implementable before putting in the work of anything DIP related.

 And sometimes other people are able to spot problems at this level.
Yes, I'm not objecting to that. I'm objecting to significant feature design discussions in a pull request. If a PR needs implementation scrutiny or needs CI testing, fine, submit a PR. But it would be good to remind people in the top PR description not to critique the feature design, and link to a DIP ideas thread so that they have somewhere to vent their feature design comments. The DIP ideas forum does not need a full technical DIP document, it just needs to communicate the core ideas.
It will still happen, not everything need nor should be a DIP, or even an ideas thread. The reality is, forcing people to move mediums, even channels kills conversation. This happens on Discord often enough that I avoid telling people to change channels. It will function as a handbrake on D's development.
Oct 16
parent Nick Treleaven <nick geany.org> writes:
On Friday, 16 October 2026 at 19:35:52 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
 It will still happen, not everything need nor should be a DIP, 
 or even an ideas thread.
Yes, but it is clear sometimes that a PR implements major design decisions, and the author will know whether there has been either forum discussion of those or DLF approval. If not, discussion will be needed, and a PR is not the right place. Even a GitHub issue is better than a PR, because then the discussion doesn't get in the way of the implementation review.
 The reality is, forcing people to move mediums, even channels 
 kills conversation. This happens on Discord often enough that I 
 avoid telling people to change channels.

 It will function as a handbrake on D's development.
Which is why I suggested to start a DIP ideas thread and post the link in the description of the PR, so that people know where the conversation is happening.
Oct 17
prev sibling parent Dennis <dkorpel gmail.com> writes:
On Wednesday, 14 October 2026 at 09:48:24 UTC, Nick Treleaven 
wrote:
 How can we stop this? When anyone sees this happen and there is 
 no disclaimer in the PR, anyone should add a warning not to 
 critique the design in the PR and to open a forum thread 
 instead.
Thanks for bringing this up. I agree and want to enforce this.
Oct 15