[Links]: Consolidate issues

[joshbruce]

This issue consolidates all issues related to the generating of links. Issues will be closed, PRs will remain open - unless they have merge conflicts.

[Feder1co5oave]

I have to be honest Josh, I don't see the rationale behind this methodology. I'm trying to help resolve the issues, but how can I keep track of which of them are solved/unresolves if you close all of them indiscriminately?
For me it would be best to close resolved or non-issues, mark duplicates and leave open those who might lead to fixing marked the right way.

Federico

[joshbruce]

@Feder1co5oave: That's fair and well-appreciated feedback. I might have been looking at it primarily from me scoping things out alone and thinking of what might be stopping people from participating in the conversation or doing what I was doing. 700+ issues across 15+ pages...versus 100 issues 6 of which are there just to group things into themes...solve the analysis paralysis problem.

I was also thinking that we would be able to remove the references once we had triaged them (never tried this methodology before)...that's apparently not possible.

We could create more labels as a filtering mechanism - that's really all this methodology gives us beyond the reduction - the "one list" so to speak (this one spans 500 issue identifiers; so, maybe it makes the original intent more obvious).

How about this...in the comments of the issues you think might actually help and aren't duplicates of something else - say so - I will reopen those issues but leave the rest closed (I think I've only seen the ones you thought were non-issues so haven't done that yet). I will also create labels for the groupings we have so far to allow simple grouping of future issues. We'll still leave the PRs open by default - we might even be able to update the submission with "Fixes" to close a related issue.

Sound fair and reasonable?

[Feder1co5oave]

Yes Josh, that sounds awesome. I see that your intent was to filter out and group together related issues, and that's good. IMO labels work great for that, since discussions relative to the issues mostly happen in the issue pages themselves. Thank you for your help!

[Feder1co5oave]

To-do list

toward 0.4.0:

• Square brackets in link description #482 should hopefully be fixed by my Handle backslash-escaped brackets in link description #996
• Links incorrectly receive markup #574 not an issue, by design
• Parse complicated url problem #366 Marked does not handle links with parentheses #690 URLs with parentheses are not converting properly. #619 Conversion failed link, there are () when #736 Trailing ) dropped in javascript links #586 still to be fixed (balanced/escaped parens in URLs - this is a priority). There's PR changed regex to allow parenthesis in link names #600 but it looks awful to me.
• link definition title on line following link url is parsed as a separate paragraph #498 is to be fixed to comply with the spec (not a priority though) - fixed by [commonmark] Make link definitions commonmark compliant #1018
• Hash links with "&" are not converted the same way as github links #857 is really about headings, and there's no perfect way to generate IDs; still we could improve the default behaviour
• Links starting with www. #890 fixed by [commonmark]+[gfm] make autolinks compliant #1034
• Emphasized URL with underscores #872 is about emphasize, not easily fixable
• Does not Handle Markdown Escapes In Link Href #829 and Escaped characters are ignored in url's #229 are both about backslash-escaping
• 65 haven't looked into this, may be a critical security issue (XSS)
• Do not autolink a trailing "!" in a URL #1027 to comply with gfm and commonmark, pr Do not autolink a trailing "!" in a URL #638 needs review and rebase -> PR [commonmark]+[gfm] make autolinks compliant #1034

[joshbruce]

Re #574 - I'm leaving it closed for now, unless we know the GFM doesn't work as expected in that case...given the solution provided in the comments. #600 is no lacking tests and has a merge conflict - closing it.

"moved" #857

[sbliven]

@joshbruce This suggestion comes a bit late, but you might want to consider using github projects for grouping together related issues if they should remain open. On the other hand, I approve of ruthlessly closing issues if it improves the organization of the discussion.

[joshbruce]

@sbliven: Never too late! :)

I enjoy the projects functionality and did set one up when I first got here to try and triage PRs: https:/chjj/marked/projects/1?

Wasn't sure what all the community could do with them (move cards, create cards, and so on) compared to registered collaborators. No one responded; so, decided to go with old-faithful methods until the community was a little more prepared. Think GitHub Projects are still a less known feature.

tl;dr: I'm with you. Just not sure the community desire is there yet.

[Feder1co5oave]

I never used projects tbh, I think milestones work well, as long as you pay attention to close solved issues and keep unsolved ones open (:winkwink: to @joshbruce)

I like having the possibility to group issues related to the same feature together, like I did a couple times with task lists, but keeping track of the state of referenced issues is not easy.

My thought on the ideal workflow:
A new issue is reported. It should be reviewed, then if it is verified as an existing problem, it is categorized and assigned to the no-defects milestone. When a pr that solves that issue (use the fixes #issue in the description to link the two) is posted, reviewed and merged, github automatically closes that issue and advances the milestone progress.

[joshbruce]

@Feder1co5oave: I agree with that flow. Projects is definitely something a bit new to the GitHub universe. I try to accept people and teams for where they are then help them get where they want to be - even if it's not where I want them to be (not about me and all that).

There seem to be various workflows near as I can tell...maybe we should move this to a different issue to keep this issue clean:

Issue -> discussion -> PR -> discussion -> merge or close

PR -> discussion -> merge or close

Think where my brain was going:

Multiple ticket types to cover most scenarios - broken (repair), annoying (repair), r&r (maintenance), new feature policy-driven (innovation), new feature user-driven (innovation). (Note: We're in repair mode right now.)

I don't think this changes either flow possibility from above; however, it does call into question whether each PR should have a related issue - come contributors seem to be operating this way.

With this setup, we can use GitHub Projects more for laying out the future (only using milestones at the moment), while working with the present, if that makes sense. To your point on keeping track of the defects, the task board can help with that as well (at least for visual people like me).

Wanna try it for a month or so, see what happens?

Tagging in @UziTech, @Feder1co5oave, and @KostyaTretyak

[joshbruce]

ps. One of the other nice things about projects is that we can add "notes" - which are not issues. This could be used to replace the checkbox/task list to break down issue tickets. Gonna make a board for 0.4.0 - if it gets used, cool - if not, no worries.

[Feder1co5oave]

Pull requests can either fix an already open issue, or report an issue themselves and propose a fix at the same time. No need for a separate issue in this case.

Things I like about task lists: I can update them (and you can too).
Things I don't like about projects: I can't do anything with them.

[joshbruce]

@Feder1co5oave: Hmmmmm...that was the question posed in #956. So, as an "unofficial" collaborator you can't move the cards and whatnot in the projects? Or create something? None of that functionality is open to you?

[Feder1co5oave]

Can't do any of that, no.

[joshbruce]

Lame. But good to know. We'll keep going as we are then and just keep trying to improve. Will see about reaching out GitHub about whitelisting people somehow other than collaboration - man, I wish I owned this repo.