These are chat archives for ractivejs/ractive

5th
Sep 2018
Chris Reeves
@evs-chris
Sep 05 2018 08:00
rolling up modules of any size
I have a project that's dies hard after about 20 good minutes of changes with rollup in watch mode
Martin Kolárik
@MartinKolarik
Sep 05 2018 10:48
could be a memory leak or something related to watch mode
I hope it won't be that bad for one-time bundling
maybe I'm wrong but I expect the overall speed of bundling to be a bigger problem than resources it uses
Joseph
@fskreuz
Sep 05 2018 12:53
Rollup was meant to be a cli tool after all :grin: Assumed environment is a CI... or a machine running 1.21 gigawatts of power and infinite RAM. :grin:
Cerem Cem ASLAN
@ceremcem
Sep 05 2018 19:06
@fskreuz I remember you said "A conversation may continue even though the issue is Closed", right?
Joseph
@fskreuz
Sep 05 2018 19:06
Yup.
Cerem Cem ASLAN
@ceremcem
Sep 05 2018 19:07
objection: it's very hard to track which conversations is being continued and which are not if the issue traffic is very intensive
I closed many issues opened by myself in another repository in order to follow your suggestion; now I'm preparing a Trello card (checklist) to track which closed issues still contain ongoing conversations :D
Chris Reeves
@evs-chris
Sep 05 2018 19:10
that's also a good use for labels
Joseph
@fskreuz
Sep 05 2018 19:10

In Github, an issue has 3 states:

  • Open: Issue open, work may be needed/ongoing, discussions open.
  • Closed: Issue closed, work stopped/postponed, discussions still open.
  • Locked: Issue cannot be interacted with at all by non-contributors.

This last state is often used to stop discussion altogether since usually it prevents non-contributors from adding more comments.

Chris Reeves
@evs-chris
Sep 05 2018 19:11
you can close stuff that's not an "issue" per se, but it makes them easier to find
lots of quality trackers count open issues against you, especially if they're open for a long time
Cerem Cem ASLAN
@ceremcem
Sep 05 2018 19:11
labels can't be an option here, because repository is not mine
Chris Reeves
@evs-chris
Sep 05 2018 19:13
ah, that's unfortunate
it probably carries a bit per
Cerem Cem ASLAN
@ceremcem
Sep 05 2018 19:14
when I faced with that "issue", I thought that Github should let every user put any label on any issue on any repository
Chris Reeves
@evs-chris
Sep 05 2018 19:14
varies* a bit per org
Cerem Cem ASLAN
@ceremcem
Sep 05 2018 19:14
users will only see the labels put by owners and themselves
Joseph
@fskreuz
Sep 05 2018 19:15
Hmm... I've always wondered if GH supports letting the author add the labels. I've never looked into it though.
Only one way to find out! :grin:
Cerem Cem ASLAN
@ceremcem
Sep 05 2018 19:16
nah... I already tried as you said :))
Chris Reeves
@evs-chris
Sep 05 2018 19:16
I wonder if there's a repo setting for that
cause it makes sense to allow it in some places
but I see where you'd definitely want to disallow it for lots of stuff
Cerem Cem ASLAN
@ceremcem
Sep 05 2018 19:18

cause it makes sense to allow it in some places

remembered now, I was putting labels in github just like I would do in forums, ie. "[DUPLICATE] ...". so the author should be perfectly able to add some labels

Joseph
@fskreuz
Sep 05 2018 19:18
Chris Reeves
@evs-chris
Sep 05 2018 19:22
jeez
Joseph
@fskreuz
Sep 05 2018 19:24
Also, a closed issue discussion scenario works like:
  • Author opens issue.
  • Repo owners think its non-issue/wontfix, closes it. OR Author closes it
  • Author/someone else insists it's an issue, continues discussion.
  • Everyone who chimed in and watching the repo still gets notifications.
  • Discussion continues.
  • Repo owners convinced, reopens issue.
If the Author/someone is persistent, that issue, even though closed will come up always in Github notifs.
Otherwise, that closed issue will die on its own.
The TypeScript repo is one good example of this, especially language feature requests. Discussions happen waaay after the issue was closed. Always comes back in github notifs.
Chris Reeves
@evs-chris
Sep 05 2018 19:28
oh man, some of those typescript issues
that and vscode
like a gazillion and a half
Cerem Cem ASLAN
@ceremcem
Sep 05 2018 19:30
@fskreuz I totally agree with you, but, this case is a bit different. I've opened +40 issues in 3 weeks and repo owner is very active (so do I), which leads an intensive traffic that can't be tracked with notifications or like. I don't know, maybe that much traffic is rare so it might be a specific, but, here we are
Joseph
@fskreuz
Sep 05 2018 19:35
In that case, the issues are active/being considered, I'd leave them open.
Cerem Cem ASLAN
@ceremcem
Sep 05 2018 19:35
since I'm a total newbie in that project, when he puts a comment, it may take my hours to follow what he suggests, which leads the tasks overlap eachother (hmm. maybe I should create a mail filter for the repo and just set as "unread" the ongoing issues)
Joseph
@fskreuz
Sep 05 2018 19:37

it may take my hours to follow what he suggests, which leads the tasks overlap eachother

A good use case for the "assignee" field. :grin: