On Sunday, 31 December 2017 at 07:43:35 UTC, Walter Bright wrote:
> On 12/30/2017 11:23 PM, IM wrote:
>> While we are discussing it here, could you please let me know what the bug triage process for each release cycle is? Is it random that anyone picks up whatever bug s/he feels like fixing? Or is it that if contributors will contribute X number of patches this cycle, then there is some sort of guidance and direction of this effort towards fixing some high priority bugs?
>
> Bugs are ranked by severity, but generally what gets fixed are bugs that a particular person self-selects an interest in fixing it.
>
> Often people who just want to help out will peruse the buglist looking for issues that match their skill levels that they can fix.

I hope that you could see that this doesn't scale very well, and some kind of a process needs to be established to shape and direct the efforts. Some thoughts/suggestions:
- Weekly meeting to review open bugs, adjust their components and priority appropriately, and assign to potential owners (those who can or likely to fix the bugs. Owners can then reassign or unassign if not interested).
- Maybe ask someone to volunteer for triaging bugs in each component. So every component has an owner.
- If a bug has been assigned to someone and hasn't received any attention (i.e. remained open for say 3 months), a bot should unassign it so that it returns back to the triage pool, hoping that it will catch the attention of the triage volunteers.

What do you think? Do you agree that a process is needed?

On Sunday, 31 December 2017 at 11:27:41 UTC, Seb wrote:
> Yes, Dlang-bot was able to detect stalled issues for a while, but we didn't turn this on for all repositories. I have just enabled it:
>
> https://github.com/dlang-bots/dlang-bot/pull/153
>
> For the moment, it is just labelling issues with e.g. "needs work", "needs rebase", "stalled", "stalled-stable".
> In a next stage it will start to actively ping people or close PRs.
> Also automatically rebasing PRs if there are no conflicts is on the radar (the GitHub UI is quite conservative in this regard).

Awesome. Thanks for all your hard work on the automation side of things, by the way. It's not glamorous but it's a huge force multiplier.

On Sunday, 31 December 2017 at 11:18:26 UTC, Seb wrote:
> On Saturday, 30 December 2017 at 02:50:48 UTC, Adam D. Ruppe wrote:
>> Bugzilla was the most well-known solution at the time. Keep in mind the D bugzilla has been around since 2006. As far as I understand it, migration at this point is deemed a big pain.
>
> No it wouldn't be a big pain. There are many tools for automatically migrating issues from Bugzilla. The only thing depending on Bugzilla is the changelog generator, but it's API calls to Bugzilla can be replaced with GitHub API calls within an hour.
> So the entire migration could be easily done in a lot less than a day.
>
> The only reason we still use Bugzilla is that the core people are used to it. Here are a couple of the common arguments:
>
> 1) Bugzilla is our, we don't want to depend on GitHub
>
> The D ecosystem already heavily depends on GitHub. Exporting the issues from GitHub would be easy. Besides there is only one person with access to the Bugzilla server.
>
> 2) GitHub only has per registry issues
>
> Bugzilla uses components too, they don't support global issues either. Besides if that's required one could easily create a meta repository for such global tasks.
>
> 3) Bugzilla's issue tracker is more sophisticated
>
> Sure, but does this help when you loose out on many contributors?
> GitHub even has build tools and sites that let anyone discover "easy" issues if they are labeled accordingly. It's free marketing.
>
> FYI I asked the same question 1 1/2 years ago: https://forum.dlang.org/post/ezldcjzpmsnxvvncncsi@forum.dlang.org
>
> Since then, for example, GitHub got voting for issues, but Bugzilla lost it.

I wholeheartedly agree. The customer is always right, especially when you're trying to get them to donate their time to an open source project. It's more essential than ever that we lower barriers to participation; if Github issues is the hip new thing all the kids like, then we need to switch to that. We shouldn't be constantly switching to the shiniest new toy, but nor should we stubbornly stick to a piece of software that was built (and it looks it) in '90s.

Or at least we should if we're trying to attract the kind of people for whom not using Github is a deal breaker. Older C++/Java programmers likely don't care, but younger Python/Ruby/JS users will.

On Sunday, 31 December 2017 at 05:43:57 UTC, Walter Bright wrote:
> Please join and help out.

I already have, and like I said there are problems with with the current system. I don't feel like helping anymore cause anything time I do my work just get dumped, and I've simply wasted my time.

> Bugs are ranked by severity, but generally what gets fixed are bugs that a particular person self-selects an interest in fixing it.
>
> Often people who just want to help out will peruse the buglist looking for issues that match their skill levels that they can fix.

You've just admitted to the problem. And those that want to "help out" will "persue the buglist looking for issues".

Then you drop this quote, "it's fine for those that want to put in a wasteful time of effort, cause they care enough".

> It's working well enough for those who care enough to make an effort.

Fix your shit if you want help, it's broken and just wastes people's time. Saying that people don't care enough is not helping with a solution.

On Saturday, 30 December 2017 at 16:36:57 UTC, Iain Buclaw wrote:
>
> Hey, I take offence to that.
>
> https://issues.dlang.org/show_bug.cgi?id=17839
>
> https://github.com/dlang/dmd/pull/7503 https://github.com/dlang/dmd/pull/7508 https://github.com/dlang/dmd/pull/7509 https://github.com/dlang/dmd/pull/7510 https://github.com/dlang/dmd/pull/7527 https://github.com/dlang/dmd/pull/7536
>
> And many more closed that were even older, and I'm not the only one reviving these patches, all of which are either abandoned, incomplete, or too controversial (there is always a valid reason why open PRs were left to rot).


I haven't been looking recently. At least there's one vigilante working in the shadows, doing the things no one else is willing to.

On 12/31/2017 8:18 AM, IM wrote:
> What do you think? Do you agree that a process is needed?

We've tried adding process before. It does not work, for the simple reason that it requires a dedicated group of people to dedicate time to it. Are you willing to do that?

We have added process when someone has stepped up to do the thankless job of administering it.

On 12/31/2017 12:53 PM, Muld wrote:
> Fix your shit
A word to the wise. Being rude will just get you ignored by most everyone on this n.g. We insist on professional demeanor and courtesy at all times. Egregious behavior will get posts unceremoniously removed.

On Sunday, 31 December 2017 at 19:49:07 UTC, Meta wrote:
> On Sunday, 31 December 2017 at 11:18:26 UTC, Seb wrote:
>> On Saturday, 30 December 2017 at 02:50:48 UTC, Adam D. Ruppe wrote:
>>> Bugzilla was the most well-known solution at the time. Keep in mind the D bugzilla has been around since 2006. As far as I understand it, migration at this point is deemed a big pain.
>>
>> No it wouldn't be a big pain. There are many tools for automatically migrating issues from Bugzilla. The only thing depending on Bugzilla is the changelog generator, but it's API calls to Bugzilla can be replaced with GitHub API calls within an hour.
>> So the entire migration could be easily done in a lot less than a day.
>>
>> The only reason we still use Bugzilla is that the core people are used to it. Here are a couple of the common arguments:
>>
>> 1) Bugzilla is our, we don't want to depend on GitHub
>>
>> The D ecosystem already heavily depends on GitHub. Exporting the issues from GitHub would be easy. Besides there is only one person with access to the Bugzilla server.
>>
>> 2) GitHub only has per registry issues
>>
>> Bugzilla uses components too, they don't support global issues either. Besides if that's required one could easily create a meta repository for such global tasks.
>>
>> 3) Bugzilla's issue tracker is more sophisticated
>>
>> Sure, but does this help when you loose out on many contributors?
>> GitHub even has build tools and sites that let anyone discover "easy" issues if they are labeled accordingly. It's free marketing.
>>
>> FYI I asked the same question 1 1/2 years ago: https://forum.dlang.org/post/ezldcjzpmsnxvvncncsi@forum.dlang.org
>>
>> Since then, for example, GitHub got voting for issues, but Bugzilla lost it.
>
> I wholeheartedly agree. The customer is always right, especially when you're trying to get them to donate their time to an open source project. It's more essential than ever that we lower barriers to participation; if Github issues is the hip new thing all the kids like, then we need to switch to that. We shouldn't be constantly switching to the shiniest new toy, but nor should we stubbornly stick to a piece of software that was built (and it looks it) in '90s.
>
> Or at least we should if we're trying to attract the kind of people for whom not using Github is a deal breaker. Older C++/Java programmers likely don't care, but younger Python/Ruby/JS users will.

there are three things that i've noticed:

- in this thread, there is not a single positive post by walter. none. nada. zilch. it'd have been much better if he just did not post anything.

- d leadership is dusty and so are their tools. we are no js community and hope we never become anything like them but bugzilla is a hundred years old. i am on github, i am on this ml and i also need a bugzilla account? what else do i need to be a part of this community? why can't you provide me a seamless travel in between? have a forum software, allow me to sign in via github and i am a member of the community. but no, they love their ugly bugzilla, they love their mailing list.

- has anyone realized we do not attract anyone who has just started to learn programming? what are we going to do about it?

On Sunday, 31 December 2017 at 21:16:35 UTC, Walter Bright wrote:
> On 12/31/2017 8:18 AM, IM wrote:
>> What do you think? Do you agree that a process is needed?
>
> We've tried adding process before. It does not work, for the simple reason that it requires a dedicated group of people to dedicate time to it. Are you willing to do that?
>
> We have added process when someone has stepped up to do the thankless job of administering it.

Well, I've spent the last few months just learning the language, debating issues on this forum, and fending off the occasional attack. This is probably what most newcomers will go through too..

For the most part, I think D is a really nice language to 'play' with, and thanks to all those that have made it happen.

Now as I think about moving from just playing with D, to making serious use of it, this lack of 'process' you mention, could become a real deal breaker.

The D Foundation should take this matter very seriously, in my opinion, and invest in process, rather than just hoping it will emerge out of the chaos of bugzilla.

By not focusing your attention on this more, I believe you risk a lot of people refusing to contribute to D, and even turning away from D. You also risk fragmentation in the D community.

Now, that asisde, happy New Year to you, and all.

Lets' make it a great year to advance D even further...

On Sunday, December 31, 2017 11:18:26 Seb via Digitalmars-d wrote:
> On Saturday, 30 December 2017 at 02:50:48 UTC, Adam D. Ruppe
>
> wrote:
> > On Saturday, 30 December 2017 at 02:37:24 UTC, IM wrote:
> >> Just curious, why Bugzilla and not something else?
> >
> > Bugzilla was the most well-known solution at the time. Keep in mind the D bugzilla has been around since 2006. As far as I understand it, migration at this point is deemed a big pain.
>
> No it wouldn't be a big pain. There are many tools for
> automatically migrating issues from Bugzilla. The only thing
> depending on Bugzilla is the changelog generator, but it's API
> calls to Bugzilla can be replaced with GitHub API calls within an
> hour.
> So the entire migration could be easily done in a lot less than a
> day.
>
> The only reason we still use Bugzilla is that the core people are used to it. Here are a couple of the common arguments:

I honestly am unaware of any reason why using github issues would be superior to bugzilla except that some folks expect projects on github to use github issues for bug reports. And plenty of projects on github don't use github issues.

If we were starting from scratch, then maybe it would make sense to use github issues instead of our own bugzilla, but given that we already have bugzilla, it works just fine, and github issues really don't seem to offer anything significant that would make them superior to using bugzilla, I really don't see any reason to switch.

> 1) Bugzilla is our, we don't want to depend on GitHub
>
> The D ecosystem already heavily depends on GitHub. Exporting the issues from GitHub would be easy. Besides there is only one person with access to the Bugzilla server.

Yes, it would be a pain to switch away from github at this point, but if github went down permanently tomorrow, it would just be an annoying roadblock. We almost certainly wouldn't lose any code (at most, a few commits, if no one pulled recently enough), and we wouldn't lose any bug reports. We'd have to go to the trouble of setting up our own gitlab or switching to bitbucket or something like that and pointing all of the automated stuff to the new place, and it would be a royal pain, but we wouldn't lose any information. If all of the issues were on github, and github went away, we'd lose them.

Sure, github is unlikely to go away, but I see no reason to tie ourselves to it thoroughly enough that we're going to lose data if they go away - especially since I don't actually see any benefit in switching to github issues.

> 2) GitHub only has per registry issues
>
> Bugzilla uses components too, they don't support global issues either. Besides if that's required one could easily create a meta repository for such global tasks.

Well, it wouldn't be the end of the world if the issues were separated by repos, but having them in a single place where they can be searched together is beneficial, and it makes it easier to switch an issue between components when it turns out that it was assigned to the wrong component. Certainly, switching to github would be negative in this regard, even if it wouldn't be a deal breaker.

> 3) Bugzilla's issue tracker is more sophisticated
>
> Sure, but does this help when you loose out on many contributors? GitHub even has build tools and sites that let anyone discover "easy" issues if they are labeled accordingly. It's free marketing.

I seriously doubt that we've lost many (if any) contributors because we don't use github issues, and plenty of other projects use github without using it as their issue tracker.

> FYI I asked the same question 1 1/2 years ago: https://forum.dlang.org/post/ezldcjzpmsnxvvncncsi@forum.dlang.org
>
> Since then, for example, GitHub got voting for issues, but Bugzilla lost it.

To be honest, no one seems to pay attention to voting on issues. Having a voting system is theoretically beneficial, but in practice, it doesn't seem to have generally had much effect on what gets fixed (not for us anyway). Almost inevitably, the stuff that actually gets many votes is the hard stuff that is likely to be sitting around whether folks vote on it or not. Plenty of those issues really should be fixed sooner, but having a lot of votes on them isn't what does it. e.g. issue #314 sat around for ages in spite of everyone agreeing that it needed to be fixed, because it a was a hard problem, and no one stepped up to the plate to take care of it. The fact that it had a bunch of votes really didn't matter.

In any case, I have yet to see much on argument for why we would even want to switch to github issues. It just seems like some folks think that for some reason, the fact that we have our code up on github means that we should have our issue tracker there too and that it's weird that we don't. Personally, I don't see any reason to go to the trouble of searching and invalidating years worth of links just because using github issues seems to be the hip thing to do. It needs to provide serious value over using our own bugzilla, and I am unaware of anything that it does that is significantly better than using bugzilla.

- Jonathan M Davis