On Tuesday, 19 January 2021 at 00:12:49 UTC, Max Haughton wrote:

> The second category is a bit looser, as there are some things I'd like to do that come under the community relations remit that aren't as structured - e.g. I am very interested in getting a proper working group together to try and iterate through designs properly rather than incremental DIPs.

That would be great!

On Tuesday, 19 January 2021 at 09:33:26 UTC, Paolo Invernizzi wrote:
> On Tuesday, 19 January 2021 at 00:12:49 UTC, Max Haughton wrote:
>
>> The second category is a bit looser, as there are some things I'd like to do that come under the community relations remit that aren't as structured - e.g. I am very interested in getting a proper working group together to try and iterate through designs properly rather than incremental DIPs.
>
> That would be great!

+1

On Tuesday, 19 January 2021 at 00:12:49 UTC, Max Haughton wrote:
> The second category is a bit looser, as there are some things I'd like to do that come under the community relations remit that aren't as structured - e.g. I am very interested in getting a proper working group together to try and iterate through designs properly rather than incremental DIPs.

Excited to see what comes from this.

Welcome Max and congratulations!

On Thursday, 21 January 2021 at 10:53:47 UTC, Walter Bright wrote:
>
> Welcome Max and congratulations!

Thanks everyone

On 18.01.21 10:21, Mike Parker wrote:
> Thanks once more to Symmetry Investments, we have a new paid staffer in the D Language Foundation family.
> 
> Though I call him my "assistant", I can already see he will be more than that. He'll be taking some things off my shoulders, sure, but he also has ideas of his own to bring into the mix. Adding him to the team is certain to be a boon for the D community.
> 
> So, a word of warning to those of you who haven't heard from me in a while pestering you for blog posts: get used to the name "Max Haughton".
> 
> And congratulate him while you're at it!

Congratulations. However, Max seems to be just closing all enhancement requests on bugzilla as invalid. This is the behavior of a vandal. Please stop. Any policy that requires this is ill-advised. Issues are valuable and binning them like this is disrespectful to the time of the reporters.

On Sunday, 24 January 2021 at 12:36:16 UTC, Timon Gehr wrote:
> On 18.01.21 10:21, Mike Parker wrote:
>> Thanks once more to Symmetry Investments, we have a new paid staffer in the D Language Foundation family.
>> 
>> Though I call him my "assistant", I can already see he will be more than that. He'll be taking some things off my shoulders, sure, but he also has ideas of his own to bring into the mix. Adding him to the team is certain to be a boon for the D community.
>> 
>> So, a word of warning to those of you who haven't heard from me in a while pestering you for blog posts: get used to the name "Max Haughton".
>> 
>> And congratulate him while you're at it!
>
> Congratulations. However, Max seems to be just closing all enhancement requests on bugzilla as invalid. This is the behavior of a vandal. Please stop. Any policy that requires this is ill-advised. Issues are valuable and binning them like this is disrespectful to the time of the reporters.

I was going through trying to close things that are either not bugs anymore because they haven't been touched from 2010 and they've been fixed by entropy, or language changes which will never be looked at again because they aren't DIPs. They're still in public record but fundamentally they're just not useful anymore - I was literally just going through bugs FILO and trying to either reproduce or at least characterise whether they even can be acted on by the foundation.

It's entirely possible I was overzealous and if I was, obviously reopen them but ultimately the enhancements have to go through a DIP because it's not 2012 anymore.

I also updated Stephen S's shared-delegate race condition bug to have a test case that actually compiles, and that's from 2010 - theadsan catches it now although it doesn't work with @safe either so I'm not sure whether we should be embarrassed or not.

On 24.01.21 14:00, Max Haughton wrote:
> On Sunday, 24 January 2021 at 12:36:16 UTC, Timon Gehr wrote:
>> On 18.01.21 10:21, Mike Parker wrote:
>>> Thanks once more to Symmetry Investments, we have a new paid staffer in the D Language Foundation family.
>>>
>>> Though I call him my "assistant", I can already see he will be more than that. He'll be taking some things off my shoulders, sure, but he also has ideas of his own to bring into the mix. Adding him to the team is certain to be a boon for the D community.
>>>
>>> So, a word of warning to those of you who haven't heard from me in a while pestering you for blog posts: get used to the name "Max Haughton".
>>>
>>> And congratulate him while you're at it!
>>
>> Congratulations. However, Max seems to be just closing all enhancement requests on bugzilla as invalid. This is the behavior of a vandal. Please stop. Any policy that requires this is ill-advised. Issues are valuable and binning them like this is disrespectful to the time of the reporters.
> 
> I was going through trying to close things that are either not bugs anymore because they haven't been touched from 2010 and they've been fixed by entropy,

I can get behind this. You closed one of my issues that was fixed this way, but I don't usually report INVALID issues, this is why there is a WORKSFORME category.

> or language changes which will never be looked at again because they aren't DIPs.

Of course they won't be looked at again if you claim they are invalid just by virtue of being enhancement requests. Obviously you looked at them now, so your reasoning here makes no sense. This is why there is an enhancement request category in the first place. They are not invalid issues, they are enhancement request issues.

> They're still in public record but fundamentally they're just not useful anymore

Issues are not useful anymore when they are fixed or there is a good reason why they should not be fixed.

> - I was literally just going through bugs FILO and trying to either reproduce or at least characterise whether they even can be acted on by the foundation.
> ...
Why does it seem like people who are hired to help improve D instead always start closing bugzilla issues without actually fixing them? This is meaningless optimization of indicators that don't even mean what you seem to think they mean. It's a waste of time and resources.

> It's entirely possible I was overzealous and if I was, obviously reopen them

I don't have time for that, I don't get notified for all of them, just the ones I reported or interacted with. I have no idea what other potentially valuable enhancement requests you closed with a condescending "INVALID" verdict just because they were enhancement requests.

Please reopen all enhancement requests that you closed even though they remain unfixed.

> but ultimately the enhancements have to go through a DIP because it's not 2012 anymore.
> ...

That does not change what those enhancement requests are for, it just makes it a bit harder to fix them. Obviously, nowadays the proper way to get rid of enhancement requests is by pushing them through the DIP process (or perhaps just making a good point to the reporter why it would be a bad idea to implement them), but of course, that requires more work than a couple of clicks and button presses. Closing as invalid because it is an enhancement request is not a valid way to get rid of enhancement requests.

If you really want to enact a policy that new enhancement requests should be illegal, I guess DLF can do that even though it is obviously a stupid idea (a DIP is a lot more formal, a large bar to overcome, so you will lose a lot of ideas), but how about you at least don't close issues that were made at a time when this was the officially encouraged way to track ideas? IMNSHO it should stay this way, there is no reason to dislike enhancement requests. They don't have the same purpose as DIPs (and DIPs are sometimes even necessary to fix issues that are not enhancement requests, for example type system unsoundness).

> I also updated Stephen S's shared-delegate race condition bug to have a test case that actually compiles, and that's from 2010 - theadsan catches it now although it doesn't work with @safe either so I'm not sure whether we should be embarrassed or not.
> 

There is certainly useful work to be done in the issue tracker. I am here objecting to certain systematic destructive practices that do not even have any upside. I wish this kind of behavior would stop forever. You are not the first person to engage into careless issue closing sprees. I think the underlying issue is a bad understanding of the value of issues in the issue tracker and some sort of irrational assignment of cost to open issues. Walter always says: Put this in bugzilla, it will get lost on the forums, and he is right.

On Sunday, 24 January 2021 at 13:49:20 UTC, Timon Gehr wrote:
> On 24.01.21 14:00, Max Haughton wrote:
>> [...]
>
> I can get behind this. You closed one of my issues that was fixed this way, but I don't usually report INVALID issues, this is why there is a WORKSFORME category.
>
> [...]

I was wrong on the enhancement requests, and the WORKSFORME one shouldn't have been marked invalid but I think I misclicked.

On 1/24/2021 5:49 AM, Timon Gehr wrote:
> There is certainly useful work to be done in the issue tracker. I am here objecting to certain systematic destructive practices that do not even have any upside. I wish this kind of behavior would stop forever. You are not the first person to engage into careless issue closing sprees. I think the underlying issue is a bad understanding of the value of issues in the issue tracker and some sort of irrational assignment of cost to open issues. Walter always says: Put this in bugzilla, it will get lost on the forums, and he is right.

You're right this has come up before.

I strongly oppose closing Issues and PRs just because they are old. There must be a better and conclusive reason to close them.

We had a recent discussion about what to do with stale PRs that are years old. I opposing closing them without a conclusive reason for closing. The stale PRs do pose "drag" on things like the autotester. What I'd like is a "backburner" category for PRs, but there doesn't seem to be such a feature. So what we came up with was:

1. If it doesn't have a bugzilla issue, make a bugzilla issue for it.
2. Put a link to the stale PR in that issue.
3. Close, but do not delete, the PR.

This makes these PRs still accessible via bugzilla, and bugzilla has much better categorization abilities than github PRs do.