-
Notifications
You must be signed in to change notification settings - Fork 43
Out-of-band meeting to discuss flags #303
Comments
Out-of-band meetings are a bit difficult to make time for; is there an urgency that means we can't resolve this in the next regular meeting? |
Our next meeting is the only one before Node 12 ships, and based on today's meeting we might not have enough time to resolve this in that meeting; and I'd like to improve the flag experience before 12 is released, to avoid negative feedback. Myles also recommended an out-of-band meeting in today's meeting. I think the goal of the out-of-band meeting would be to reach a consensus among the people who have opinions one way or another on flags, and assuming we don't have quorum then at the next regular meeting the full group can approve what this splinter group decides. |
@GeoffreyBooth is this more of a digest and reflect versus planning thing, ie useful for those who want a recap absent any formal decision-making? If formal decisions are to be made, then I second @ljharb's concern on this being out of band and all. If this is regrouping for those who need to get caught up and find it hard to do so in the one-hour every other week, it helps to do that without cutting into our limited time slot — any other suggestions here are appreciated. |
Well if we can come to a consensus in #300, we won’t need a meeting. That issue was on the agenda for this past meeting but we didn’t have time to get to it, and Myles suggested an out-of-band meeting to make up for it. The Slack |
Looks like there’s not enough interest to hold this meeting. Let me put it this way: does anyone object to nodejs/ecmascript-modules#66? If so I’d like to discuss before our next regular meeting, so that I can either address the feedback or propose an alternative. We have only one meeting before Node 12 ships, so I’d like to have a PR ready for consensus in that meeting. |
How are you handling the extensionless symlinks relative to:
|
input-type wouldn’t deal with files, so it’d have no impact on symlinks; entry-type should be obeying those flags. |
I think we should discuss #300. The current
--entry-type
behavior is quite far from my intent when I first proposed the--type
flag, and I’m not convinced that--entry-type
is better than what the original proposal envisioned. Also as we’ve seen there is a lot of user confusion around the behavior of--entry-type
.Doodle: https://doodle.com/poll/skk5fdgbh7am4845
P.S. If people want to discuss flags on GitHub before the meeting, can that please happen in #300? And this thread can only concern the logistics of the meeting.
The text was updated successfully, but these errors were encountered: