digitalmars.D.internals - Drive-by feature pull requests
- Nick Treleaven (20/20) Oct 14 Recently there have been a number of pull requests that add a
- Richard (Rikki) Andrew Cattermole (6/25) Oct 14 Why stop it?
- Nick Treleaven (10/16) Oct 16 Yes, I'm not objecting to that. I'm objecting to significant
- Richard (Rikki) Andrew Cattermole (7/23) Oct 16 It will still happen, not everything need nor should be a DIP, or even
- Nick Treleaven (11/17) Oct 17 Yes, but it is clear sometimes that a PR implements major design
- Dennis (3/7) Oct 15 Thanks for bringing this up. I agree and want to enforce this.
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
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
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
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: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.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
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
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









Nick Treleaven <nick geany.org> 