profile
viewpoint

jquery-validation/jquery-validation 9839

jQuery Validation Plugin library sources

fnagel/jquery-ui 595

A fork of jQuery UI: WIP branches, legacy Selectmenu Widget (branch: selectmenu) and an accessible version of jQuery UI Tabs (outdated, branch: tabs accessability)

JSFoundation/standards 246

Giving web developers a voice in the standards process

jzaefferer/commitplease 83

Validates strings as commit messages

clarkbox/testswarm-browserstack 25

Integration layer between TestSwarm and BrowserStack

jquery-validation/validation-content 11

Content for jQuery Validation Plugin website and official docs

jzaefferer/contenteditable 6

A different approach to a richtext editor.

JamesMGreene/grunt-qunitnode 2

A Grunt task plugin to execute QUnit tests in Node.js.

jzaefferer/Cologne.js 2

A page for the javascript meetup in cologne

jquery-validation/validation-theme 1

WordPress theme for the jQuery Validation Plugin site

pull request commentnushell/rfcs

propose RFC process (meta proposal)

I'll put it in the next This Week in Nu also.

Looks like you forgot :o

jzaefferer

comment created time in 20 days

pull request commentnushell/rfcs

propose RFC process (meta proposal)

Frankly, I'd love to avoid stating it as RFC and call them Nu Plays instead.

I'm not sure how serious you are about this. I don't get the "Nu Plays" name, and I don't like the idea of the substantial rename work.

@jonathandturner do you want to feature this in the next "This week in Nushell" first? Or can it be merged now (and featured afterwards)?

jzaefferer

comment created time in 24 days

pull request commentnushell/nushell

Implement the verbose option of mkdir command.

Could you also add docs/commands/mkdir.md, including the new option?

utam0k

comment created time in a month

Pull request review commentnushell/rfcs

propose RFC process (meta proposal)

+# Nushell RFCs++[Nushell RFCs]: #nushell-rfcs++Many changes, including bug fixes and documentation improvements can be+implemented and reviewed via the normal GitHub pull request workflow.++Though some changes are substantial enough that we ask for these to be+put through a bit of a design process and produce a consensus among the+Nushell community.++The "RFC" (request for comments) process is intended to provide a consistent+and controlled path for new features to be added to Nushell, so that all+stakeholders can be confident about the direction the project is evolving in.+++## Table of Contents+[Table of Contents]: #table-of-contents++  - [Opening](#nushell-rfcs)+  - [Table of Contents]+  - [When you need to follow this process]

Good catch. I had changed the header, but missed this ToC entry. Fixed!

jzaefferer

comment created time in a month

Pull request review commentnushell/rfcs

propose RFC process (meta proposal)

+# Nushell RFCs++[Nushell RFCs]: #nushell-rfcs++Many changes, including bug fixes and documentation improvements can be+implemented and reviewed via the normal GitHub pull request workflow.++Though some changes are substantial enough that we ask for these to be+put through a bit of a design process and produce a consensus among the+Nushell community.++The "RFC" (request for comments) process is intended to provide a consistent+and controlled path for new features to be added to Nushell, so that all+stakeholders can be confident about the direction the project is evolving in.+++## Table of Contents+[Table of Contents]: #table-of-contents++  - [Opening](#nushell-rfcs)+  - [Table of Contents]+  - [When you need to follow this process]+  - [Before creating an RFC]+  - [What the process is]+  - [The RFC life-cycle]+  - [Reviewing RFCs]+  - [Implementing an RFC]+  - [RFC Postponement]+  - [License]+  - [Contributions]+  - [Acknowledgements]+++## When you should follow this process+[When you should follow this process]: #when-you-should-follow-this-process++*Note: While we establish this RFC process, this says "should"; eventually+it should say "need to".*++You should follow this process if you intend to make substantial changes to+Nushell, or this RFC process itself. What constitutes a substantial change is+evolving based on community norms and varies depending on what part of the+ecosystem you are proposing to change, but may include the following:++  - Any semantic or syntactic change that is not a bugfix.+  - Removing existing features.+  - Changes to internal interfaces, like the plugin architecture.++Some changes do not require an RFC:++  - Rephrasing, reorganizing, refactoring, or otherwise "changing shape does+    not change meaning".+  - Additions that strictly improve objective, numerical quality criteria+    (warning removal, speedup, better platform coverage, more parallelism,+    better handle errors, etc.)+  - Additions only likely to be _noticed by_ other developers of Nushell,+    invisible to users of Nushell.

I changed the line before the list to this: "Some changes do not require an RFC. For example:"

jzaefferer

comment created time in a month

Pull request review commentnushell/rfcs

propose RFC process (meta proposal)

+# Nushell RFCs++[Nushell RFCs]: #nushell-rfcs++Many changes, including bug fixes and documentation improvements can be+implemented and reviewed via the normal GitHub pull request workflow.++Though some changes are substantial enough that we ask for these to be+put through a bit of a design process and produce a consensus among the+Nushell community.++The "RFC" (request for comments) process is intended to provide a consistent+and controlled path for new features to be added to Nushell, so that all+stakeholders can be confident about the direction the project is evolving in.+++## Table of Contents+[Table of Contents]: #table-of-contents++  - [Opening](#nushell-rfcs)+  - [Table of Contents]+  - [When you need to follow this process]+  - [Before creating an RFC]+  - [What the process is]+  - [The RFC life-cycle]+  - [Reviewing RFCs]+  - [Implementing an RFC]+  - [RFC Postponement]+  - [License]+  - [Contributions]+  - [Acknowledgements]+++## When you should follow this process+[When you should follow this process]: #when-you-should-follow-this-process++*Note: While we establish this RFC process, this says "should"; eventually+it should say "need to".*++You should follow this process if you intend to make substantial changes to+Nushell, or this RFC process itself. What constitutes a substantial change is+evolving based on community norms and varies depending on what part of the+ecosystem you are proposing to change, but may include the following:++  - Any semantic or syntactic change that is not a bugfix.+  - Removing existing features.+  - Changes to internal interfaces, like the plugin architecture.++Some changes do not require an RFC:++  - Rephrasing, reorganizing, refactoring, or otherwise "changing shape does+    not change meaning".+  - Additions that strictly improve objective, numerical quality criteria+    (warning removal, speedup, better platform coverage, more parallelism,+    better handle errors, etc.)

I'm don't know how to put this into words. Could you suggest an edit?

jzaefferer

comment created time in a month

Pull request review commentnushell/rfcs

propose RFC process (meta proposal)

+# Nushell RFCs++[Nushell RFCs]: #nushell-rfcs++Many changes, including bug fixes and documentation improvements can be+implemented and reviewed via the normal GitHub pull request workflow.++Though some changes are substantial enough that we ask for these to be+put through a bit of a design process and produce a consensus among the+Nushell community.++The "RFC" (request for comments) process is intended to provide a consistent+and controlled path for new features to be added to Nushell, so that all+stakeholders can be confident about the direction the project is evolving in.+++## Table of Contents+[Table of Contents]: #table-of-contents++  - [Opening](#nushell-rfcs)+  - [Table of Contents]+  - [When you need to follow this process]+  - [Before creating an RFC]+  - [What the process is]+  - [The RFC life-cycle]+  - [Reviewing RFCs]+  - [Implementing an RFC]+  - [RFC Postponement]+  - [License]+  - [Contributions]+  - [Acknowledgements]+++## When you should follow this process+[When you should follow this process]: #when-you-should-follow-this-process++*Note: While we establish this RFC process, this says "should"; eventually+it should say "need to".*++You should follow this process if you intend to make substantial changes to+Nushell, or this RFC process itself. What constitutes a substantial change is+evolving based on community norms and varies depending on what part of the+ecosystem you are proposing to change, but may include the following:++  - Any semantic or syntactic change that is not a bugfix.+  - Removing existing features.+  - Changes to internal interfaces, like the plugin architecture.++Some changes do not require an RFC:++  - Rephrasing, reorganizing, refactoring, or otherwise "changing shape does+    not change meaning".+  - Additions that strictly improve objective, numerical quality criteria+    (warning removal, speedup, better platform coverage, more parallelism,+    better handle errors, etc.)+  - Additions only likely to be _noticed by_ other developers of Nushell,+    invisible to users of Nushell.++If you submit a pull request to implement a new feature without going through+the RFC process, it may be closed with a polite request to submit an RFC first.+++## Before creating an RFC+[Before creating an RFC]: #before-creating-an-rfc++It is generally a good idea to pursue feedback from other project developers+beforehand, to ascertain that the RFC may be desirable; having a consistent+impact on the project requires concerted effort toward consensus-building.++The most common preparations for writing and submitting an RFC include talking+the idea over on our [official Discord server], in #design-discussion. You could also file issues on this repo for discussion.++As a rule of thumb, receiving encouraging feedback from long-standing project+developers is a good indication that the RFC is worth pursuing.+++## What the process is+[What the process is]: #what-the-process-is++In short, to get a major feature added to Nushell, one must (for now: should)+first get the RFC merged into the RFC repository as a markdown file. At that+point the RFC is "active" and may be implemented with the goal of inclusion+into Nushell.++  - Fork the RFC repo [RFC repository]+  - Copy `0000-template.md` to `text/0000-my-feature.md` (where "my-feature" is+    descriptive. Leave the `0000` for now).+  - Fill in the RFC. Put care into the details: RFCs that do not present+    convincing motivation, demonstrate lack of understanding of the design's+    impact, or are disingenuous about the drawbacks or alternatives tend to+    be poorly-received.+  - Submit a pull request. As a pull request the RFC will receive design+    feedback from the larger community, and the author should be prepared to+    revise it in response.+  - Now that your RFC has an open pull request, use the issue number of the PR+    to update your `0000-` prefix to that number.+  - Where applicable, each pull request will be triaged by the team in a+    future meeting and assigned to a member of the team.+  - Build consensus and integrate feedback. RFCs that have broad support are+    much more likely to make progress than those that don't receive any+    comments. Feel free to reach out to the RFC assignee in particular to get+    help identifying stakeholders and obstacles.+  - The team will discuss the RFC pull request, as much as possible in the+    comment thread of the pull request itself. Other discussion (e.g. on+    Discord) will be summarized on the pull request comment thread.+  - RFCs rarely go through this process unchanged, especially as alternatives+    and drawbacks are shown. You can make edits, big and small, to the RFC to+    clarify or change the design, but make changes as new commits to the pull+    request, and leave a comment on the pull request explaining your changes.+    **Specifically, do not squash or rebase commits after they are visible on the+    pull request.**+  - When the RFC is in a state that justifies community attention, it should be+    advertised widely, e.g. in [This Week in Nushell](https://www.notion.so/This-Week-in-Nu-ed589e19f1be47fa9ef562c1757e7ba1).+    This way all stakeholders have a chance to lodge any final objections+    before a decision is reached.+  - At some point after advertising the RFC was advertised publicly, a member+    of the team will propose a decision for the RFC (merge, close, or postpone).+    Another team member must sign off on that decision, and can then take the+    appropriate action. When closing or postponing, the reasons need to be well+    documented in the PR.++## The RFC life-cycle+[The RFC life-cycle]: #the-rfc-life-cycle++Once an RFC becomes "active" then authors may implement it and submit the+feature as a pull request to the Nushell repo. Being "active" is not a rubber+stamp, and in particular still does not mean the feature will ultimately be+merged; it does mean that in principle all the major stakeholders have agreed+to the feature and are amenable to merging it.++Furthermore, the fact that a given RFC has been accepted and is "active"+implies nothing about what priority is assigned to its implementation, nor does+it imply anything about whether a Nushell developer has been assigned the task of+implementing the feature. While it is not *necessary* that the author of the+RFC also write the implementation, it is by far the most effective way to see+an RFC through to completion: authors should not expect that other project+developers will take on responsibility for implementing their accepted feature.++Modifications to "active" RFCs can be done in follow-up pull requests. We+strive to write each RFC in a manner that it will reflect the final design of+the feature; but the nature of the process means that we cannot expect every+merged RFC to actually reflect what the end result will be at the time of the+next major release.++In general, once accepted, RFCs should not be substantially changed. Only very+minor changes should be submitted as amendments. More substantial changes+should be new RFCs, with a note added to the original RFC. What exactly counts+as a "very minor change" is up to the team to decide.+++## Reviewing RFCs+[Reviewing RFCs]: #reviewing-rfcs++While the RFC pull request is up, the team may schedule meetings with the+author and/or relevant stakeholders to discuss the issues in greater detail,+and in some cases the topic may be discussed at a team meeting. In either+case a summary from the meeting will be posted back to the RFC pull request.++The team makes final decisions about RFCs after the benefits and drawbacks+are well understood. These decisions can be made at any time, but the team+will regularly issue decisions. When a decision is made, the RFC pull request+will either be merged or closed. In either case, if the reasoning is not clear+from the discussion in thread, the team will add a comment describing the+rationale for the decision.+++## Implementing an RFC+[Implementing an RFC]: #implementing-an-rfc++Some accepted RFCs represent vital features that need to be implemented right+away. Other accepted RFCs can represent features that can wait until some+arbitrary developer feels like doing the work. Every accepted RFC has an+associated issue tracking its implementation in the Nushell repository; thus that+associated issue can be assigned a priority via the triage process that the+team uses for all issues in the Nushell repository.++The author of an RFC is not obligated to implement it. Of course, the RFC+author (like any other developer) is welcome to post an implementation for+review after the RFC has been accepted.++If you are interested in working on the implementation for an "active" RFC, but+cannot determine if someone else is already working on it, feel free to ask+(e.g. by leaving a comment on the associated issue).

I added "; a team member can then assign you to the issue)."

jzaefferer

comment created time in a month

Pull request review commentnushell/rfcs

propose RFC process (meta proposal)

+- Feature Name: establish-rfc-process+- Start Date: 2020-05-30+- RFC PR: [nushell/rfcs#0001](https://github.com/nushell/rfcs/pull/1)+- Nushell Issue: [nushell/nushell#0000](https://github.com/nushell/nushell/issues/0000)++# Summary+[summary]: #summary++Establish an RFC process, copying Rust's process.++# Motivation+[motivation]: #motivation++Adding, extending and changing commands and their sytanx, flags and other behaviour is currently happening ad-hoc, via GitHub issues and PRs, sometimes with previous discussion on Discord. To establish a process for proposing, reviewing, accepting and implementing, or rejecting such changes, we want to copy what already works well for Rust.++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++Since this meta-RFC adds `0000-template.md` and `README.md` itself, all details can be found in those two files. Only changes to the RFC process should be allowed exceptions like this.++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++See above.++# Drawbacks+[drawbacks]: #drawbacks++While we're pre-1.0, being able to quickly change Nushell, without much discussion, might be more desirable than this formal process.++To soften the blow, for now the instruction is "should use this process", not "needs to use this process". Closer or post-1.0 that language should be changed to "needs to".++# Rationale and alternatives+[rationale-and-alternatives]: #rationale-and-alternatives++I've only looked at how Rust is doing it, so there might be better options.++The impact of not doing this could be high churn and overhead of designing only in code, with unclear pathways for discussing designs upfront.++# Prior art+[prior-art]: #prior-art++This started as a copy of Rust's RFC process, as indicated in the (additional) Achknowledgements section in the README. Their [README file](https://github.com/rust-lang/rfcs/blob/master/README.md) alone has had 29 contributiors at the time of writing this, and had plenty of time to evolve since its inception in March 2014.++# Unresolved questions+[unresolved-questions]: #unresolved-questions++The concept of the "team" is currently not well defined (to my knowledge). It doesn't exist in Rust, which instead has sub-teams (for compiler, language and libraries). Actually defining "team" for Nushell, for example as all commiters to the nushell/nushell repostiroy, would be a potential solution.

I added a definition in the Opening and replaced these two paragraph, since the question is now resolved.

jzaefferer

comment created time in a month

push eventjzaefferer/rfcs

Jörn Zaefferer

commit sha 26e14f2e01353e418f1ce781f9fa16929a576883

readme: small fixes, addressing thegedge's comments

view details

Jörn Zaefferer

commit sha 00d106af401a5c70f1ead9d68dd656213d48fe00

add definition for "team", resolve that in the first rfc

view details

push time in a month

push eventjzaefferer/rfcs

Jörn Zaefferer

commit sha 4468f6b0a5861229b9d17df3be0e0ee3163d3ea2

readme: remove irrelevant contributions section

view details

push time in a month

Pull request review commentnushell/rfcs

propose RFC process (meta proposal)

+# Nushell RFCs++[Nushell RFCs]: #nushell-rfcs++Many changes, including bug fixes and documentation improvements can be+implemented and reviewed via the normal GitHub pull request workflow.++Though some changes are substantial enough that we ask for these to be+put through a bit of a design process and produce a consensus among the+Nushell community.++The "RFC" (request for comments) process is intended to provide a consistent+and controlled path for new features to be added to Nushell, so that all+stakeholders can be confident about the direction the project is evolving in.+++## Table of Contents+[Table of Contents]: #table-of-contents++  - [Opening](#nushell-rfcs)+  - [Table of Contents]+  - [When you need to follow this process]+  - [Before creating an RFC]+  - [What the process is]+  - [The RFC life-cycle]+  - [Reviewing RFCs]+  - [Implementing an RFC]+  - [RFC Postponement]+  - [License]+  - [Contributions]+  - [Acknowledgements]+++## When you should follow this process+[When you should follow this process]: #when-you-should-follow-this-process++*Note: While we establish this RFC process, this says "should"; eventually+it should say "need to".*++You should follow this process if you intend to make substantial changes to+Nushell, or this RFC process itself. What constitutes a substantial change is+evolving based on community norms and varies depending on what part of the+ecosystem you are proposing to change, but may include the following:++  - Any semantic or syntactic change that is not a bugfix.+  - Removing existing features.+  - Changes to internal interfaces, like the plugin architecture.++Some changes do not require an RFC:++  - Rephrasing, reorganizing, refactoring, or otherwise "changing shape does+    not change meaning".+  - Additions that strictly improve objective, numerical quality criteria+    (warning removal, speedup, better platform coverage, more parallelism,+    better handle errors, etc.)+  - Additions only likely to be _noticed by_ other developers of Nushell,+    invisible to users of Nushell.++If you submit a pull request to implement a new feature without going through+the RFC process, it may be closed with a polite request to submit an RFC first.+++## Before creating an RFC+[Before creating an RFC]: #before-creating-an-rfc++It is generally a good idea to pursue feedback from other project developers+beforehand, to ascertain that the RFC may be desirable; having a consistent+impact on the project requires concerted effort toward consensus-building.++The most common preparations for writing and submitting an RFC include talking+the idea over on our [official Discord server], in #design-discussion. You could also file issues on this repo for discussion.++As a rule of thumb, receiving encouraging feedback from long-standing project+developers is a good indication that the RFC is worth pursuing.+++## What the process is+[What the process is]: #what-the-process-is++In short, to get a major feature added to Nushell, one must (for now: should)+first get the RFC merged into the RFC repository as a markdown file. At that+point the RFC is "active" and may be implemented with the goal of inclusion+into Nushell.++  - Fork the RFC repo [RFC repository]+  - Copy `0000-template.md` to `text/0000-my-feature.md` (where "my-feature" is+    descriptive. Leave the `0000` for now).+  - Fill in the RFC. Put care into the details: RFCs that do not present+    convincing motivation, demonstrate lack of understanding of the design's+    impact, or are disingenuous about the drawbacks or alternatives tend to+    be poorly-received.+  - Submit a pull request. As a pull request the RFC will receive design+    feedback from the larger community, and the author should be prepared to+    revise it in response.+  - Now that your RFC has an open pull request, use the issue number of the PR+    to update your `0000-` prefix to that number.+  - Where applicable, each pull request will be triaged by the team in a+    future meeting and assigned to a member of the team.+  - Build consensus and integrate feedback. RFCs that have broad support are+    much more likely to make progress than those that don't receive any+    comments. Feel free to reach out to the RFC assignee in particular to get+    help identifying stakeholders and obstacles.+  - The team will discuss the RFC pull request, as much as possible in the+    comment thread of the pull request itself. Other discussion (e.g. on+    Discord) will be summarized on the pull request comment thread.+  - RFCs rarely go through this process unchanged, especially as alternatives+    and drawbacks are shown. You can make edits, big and small, to the RFC to+    clarify or change the design, but make changes as new commits to the pull+    request, and leave a comment on the pull request explaining your changes.+    **Specifically, do not squash or rebase commits after they are visible on the+    pull request.**+  - When the RFC is in a state that justifies community attention, it should be+    advertised widely, e.g. in [This Week in Nushell](https://www.notion.so/This-Week-in-Nu-ed589e19f1be47fa9ef562c1757e7ba1).+    This way all stakeholders have a chance to lodge any final objections+    before a decision is reached.+  - At some point after advertising the RFC was advertised publicly, a member+    of the team will propose a decision for the RFC (merge, close, or postpone).+    Another team member must sign off on that decision, and can then take the+    appropriate action. When closing or postponing, the reasons need to be well+    documented in the PR.++## The RFC life-cycle+[The RFC life-cycle]: #the-rfc-life-cycle++Once an RFC becomes "active" then authors may implement it and submit the+feature as a pull request to the Nushell repo. Being "active" is not a rubber+stamp, and in particular still does not mean the feature will ultimately be+merged; it does mean that in principle all the major stakeholders have agreed+to the feature and are amenable to merging it.++Furthermore, the fact that a given RFC has been accepted and is "active"+implies nothing about what priority is assigned to its implementation, nor does+it imply anything about whether a Nushell developer has been assigned the task of+implementing the feature. While it is not *necessary* that the author of the+RFC also write the implementation, it is by far the most effective way to see+an RFC through to completion: authors should not expect that other project+developers will take on responsibility for implementing their accepted feature.++Modifications to "active" RFCs can be done in follow-up pull requests. We+strive to write each RFC in a manner that it will reflect the final design of+the feature; but the nature of the process means that we cannot expect every+merged RFC to actually reflect what the end result will be at the time of the+next major release.++In general, once accepted, RFCs should not be substantially changed. Only very+minor changes should be submitted as amendments. More substantial changes+should be new RFCs, with a note added to the original RFC. What exactly counts+as a "very minor change" is up to the team to decide.+++## Reviewing RFCs+[Reviewing RFCs]: #reviewing-rfcs++While the RFC pull request is up, the team may schedule meetings with the+author and/or relevant stakeholders to discuss the issues in greater detail,+and in some cases the topic may be discussed at a team meeting. In either+case a summary from the meeting will be posted back to the RFC pull request.++The team makes final decisions about RFCs after the benefits and drawbacks+are well understood. These decisions can be made at any time, but the team+will regularly issue decisions. When a decision is made, the RFC pull request+will either be merged or closed. In either case, if the reasoning is not clear+from the discussion in thread, the team will add a comment describing the+rationale for the decision.+++## Implementing an RFC+[Implementing an RFC]: #implementing-an-rfc++Some accepted RFCs represent vital features that need to be implemented right+away. Other accepted RFCs can represent features that can wait until some+arbitrary developer feels like doing the work. Every accepted RFC has an+associated issue tracking its implementation in the Nushell repository; thus that+associated issue can be assigned a priority via the triage process that the+team uses for all issues in the Nushell repository.++The author of an RFC is not obligated to implement it. Of course, the RFC+author (like any other developer) is welcome to post an implementation for+review after the RFC has been accepted.++If you are interested in working on the implementation for an "active" RFC, but+cannot determine if someone else is already working on it, feel free to ask+(e.g. by leaving a comment on the associated issue).+++## RFC Postponement+[RFC Postponement]: #rfc-postponement++Some RFC pull requests are tagged with the "postponed" label when they are+closed (as part of the rejection process). An RFC closed with "postponed" is+marked as such because we want neither to think about evaluating the proposal+nor about implementing the described feature until some time in the future, and+we believe that we can afford to wait until then to do so. This could be used+to postpone features until after 1.0. Postponed pull requests may be re-opened+when the time is right. We don't have any formal process for that.++Usually an RFC pull request marked as "postponed" has already passed an+informal first round of evaluation, namely the round of "do we think we would+ever possibly consider making this change, as outlined in the RFC pull request,+or some semi-obvious variation of it." (When the answer to the latter question+is "no", then the appropriate response is to close the RFC, not postpone it.)+++## License+[License]: #license++This repository is licensed under the MIT license ([LICENSE](LICENSE) or http://opensource.org/licenses/MIT)+++### Contributions++Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Yeah, somehow I missed that. I'll update it. I'd remove the section - saying that the license is MIT should be enough.

jzaefferer

comment created time in a month

Pull request review commentnushell/rfcs

propose RFC process (meta proposal)

+# Nushell RFCs++[Nushell RFCs]: #nushell-rfcs++Many changes, including bug fixes and documentation improvements can be+implemented and reviewed via the normal GitHub pull request workflow.++Though ssome changes are substantial enough that we ask for these to be+put through a bit of a design process and produce a consensus among the+Nushell community.++The "RFC" (request for comments) process is intended to provide a consistent+and controlled path for new features to be added to Nushell, so that all+stakeholders can be confident about the direction the project is evolving in.+++## Table of Contents+[Table of Contents]: #table-of-contents++  - [Opening](#nushell-rfcs)+  - [Table of Contents]+  - [When you need to follow this process]+  - [Before creating an RFC]+  - [What the process is]+  - [The RFC life-cycle]+  - [Reviewing RFCs]+  - [Implementing an RFC]+  - [RFC Postponement]+  - [Help this is all too informal!]+  - [License]+  - [Contributions]+  - [Acknowledgements]+++## When you should follow this process+[When you should follow this process]: #when-you-should-follow-this-process++*Note: While we establish this RFC process, this says "should"; eventually+it should say "need to".*++You should follow this process if you intend to make substantial changes to+Nushell, or this RFC process itself. What constitutes a substantial change is+evolving based on community norms and varies depending on what part of the+ecosystem you are proposing to change, but may include the following:++  - Any semantic or syntactic change that is not a bugfix.+  - Removing existing features.+  - Changes to internal interfaces, like the plugin architecture.++Some changes do not require an RFC:++  - Rephrasing, reorganizing, refactoring, or otherwise "changing shape does+    not change meaning".+  - Additions that strictly improve objective, numerical quality criteria+    (warning removal, speedup, better platform coverage, more parallelism,+    better handle errors, etc.)+  - Additions only likely to be _noticed by_ other developers of Nushell,+    invisible to users of Nushell.++If you submit a pull request to implement a new feature without going through+the RFC process, it may be closed with a polite request to submit an RFC first.+++## Before creating an RFC+[Before creating an RFC]: #before-creating-an-rfc++A hastily-proposed RFC can hurt its chances of acceptance. Low quality+proposals, proposals for previously-rejected features, or those that don't fit+into the near-term roadmap, may be quickly rejected, which can be demotivating+for the unprepared contributor. Laying some groundwork ahead of the RFC can+make the process smoother.++Although there is no single way to prepare for submitting an RFC, it is+generally a good idea to pursue feedback from other project developers+beforehand, to ascertain that the RFC may be desirable; having a consistent+impact on the project requires concerted effort toward consensus-building.++The most common preparations for writing and submitting an RFC include talking+the idea over on our [official Discord server] (*maybe later, also a discussion+forum*). You may file issues on this repo for discussion, but these are+not as actively looked at by the team.++As a rule of thumb, receiving encouraging feedback from long-standing project+developers is a good indication that the RFC is worth pursuing.+++## What the process is+[What the process is]: #what-the-process-is++In short, to get a major feature added to Nushell, one must (for now: should)+first get the RFC merged into the RFC repository as a markdown file. At that+point the RFC is "active" and may be implemented with the goal of inclusion+into Nushell.++  - Fork the RFC repo [RFC repository]+  - Copy `0000-template.md` to `text/0000-my-feature.md` (where "my-feature" is+    descriptive. Leave the `0000` for now).+  - Fill in the RFC. Put care into the details: RFCs that do not present+    convincing motivation, demonstrate lack of understanding of the design's+    impact, or are disingenuous about the drawbacks or alternatives tend to+    be poorly-received.+  - Submit a pull request. As a pull request the RFC will receive design+    feedback from the larger community, and the author should be prepared to+    revise it in response.+  - Now that your RFC has an open pull request, use the issue number of the PR+    to update your `0000-` prefix to that number.+  - Where applicable, each pull request will be triaged by the team in a+    future meeting and assigned to a member of the team.+  - Build consensus and integrate feedback. RFCs that have broad support are+    much more likely to make progress than those that don't receive any+    comments. Feel free to reach out to the RFC assignee in particular to get+    help identifying stakeholders and obstacles.+  - The team will discuss the RFC pull request, as much as possible in the+    comment thread of the pull request itself. Other discussion (e.g. on+    Discord) will be summarized on the pull request comment thread.+  - RFCs rarely go through this process unchanged, especially as alternatives+    and drawbacks are shown. You can make edits, big and small, to the RFC to+    clarify or change the design, but make changes as new commits to the pull+    request, and leave a comment on the pull request explaining your changes.+    **Specifically, do not squash or rebase commits after they are visible on the+    pull request.**+  - At some point, a member of the team will propose a "motion for final+    comment period" (FCP), along with a *disposition* for the RFC (merge, close,+    or postpone).+    - This step is taken when enough of the tradeoffs have been discussed that+      the team is in a position to make a decision. That does not require+      consensus amongst all participants in the RFC thread (which is usually+      impossible). However, the argument supporting the disposition on the RFC+      needs to have already been clearly articulated, and there should not be a+      strong consensus *against* that position. Team members use their best+      judgment in taking this step, and the FCP itself ensures there is ample+      time and notification for stakeholders to push back if it is made+      prematurely.+    - For RFCs with lengthy discussion, the motion to FCP is usually preceded by+      a *summary comment* trying to lay out the current state of the discussion+      and major tradeoffs/points of disagreement.+    - Before actually entering FCP, *all* team members must sign off; this+      might be the point at which many team members first review the RFC in full+      depth.+  - The FCP lasts ten calendar days, so that it is open for at least 5 business+    days. It is also advertised widely,+    e.g. in [This Week in Nushell](https://www.notion.so/This-Week-in-Nu-ed589e19f1be47fa9ef562c1757e7ba1).+    This way all stakeholders have a chance to lodge any final objections+    before a decision is reached.+  - In most cases, the FCP period is quiet, and the RFC is either merged or+    closed. However, sometimes substantial new arguments or ideas are raised,+    the FCP is canceled, and the RFC goes back into development mode.++## The RFC life-cycle+[The RFC life-cycle]: #the-rfc-life-cycle++Once an RFC becomes "active" then authors may implement it and submit the+feature as a pull request to the Nushell repo. Being "active" is not a rubber+stamp, and in particular still does not mean the feature will ultimately be+merged; it does mean that in principle all the major stakeholders have agreed+to the feature and are amenable to merging it.

Makes sense! I've dropped the entire FCP stage. This simplifies 'What the process is' quite a bit. I've replaced it with two simpler variations:

  • When the RFC is in a state that justifies community attention, it should be advertised widely, e.g. in This Week in Nushell. This way all stakeholders have a chance to lodge any final objections before a decision is reached.
  • At some point after advertising the RFC was advertised publicly, a member of the team will propose a decision for the RFC (merge, close, or postpone). Another team member must sign off on that decision, and can then take the appropriate action. When closing or postponing, the reasons need to be well documented in the PR.

This still provides a certain minimal duration, but without the FCP overhead.

jzaefferer

comment created time in a month

push eventjzaefferer/rfcs

Jörn Zaefferer

commit sha 95a7cfc82edb94e841295ba54789ac1b0da369a2

readme: remove fcp stage, use a simpler acceptance process One team member suggests a decision, another signs off and takes action.

view details

push time in a month

Pull request review commentnushell/rfcs

propose RFC process (meta proposal)

+# Nushell RFCs++[Nushell RFCs]: #nushell-rfcs++Many changes, including bug fixes and documentation improvements can be+implemented and reviewed via the normal GitHub pull request workflow.++Though ssome changes are substantial enough that we ask for these to be+put through a bit of a design process and produce a consensus among the+Nushell community.++The "RFC" (request for comments) process is intended to provide a consistent+and controlled path for new features to be added to Nushell, so that all+stakeholders can be confident about the direction the project is evolving in.+++## Table of Contents+[Table of Contents]: #table-of-contents++  - [Opening](#nushell-rfcs)+  - [Table of Contents]+  - [When you need to follow this process]+  - [Before creating an RFC]+  - [What the process is]+  - [The RFC life-cycle]+  - [Reviewing RFCs]+  - [Implementing an RFC]+  - [RFC Postponement]+  - [Help this is all too informal!]+  - [License]+  - [Contributions]+  - [Acknowledgements]+++## When you should follow this process+[When you should follow this process]: #when-you-should-follow-this-process++*Note: While we establish this RFC process, this says "should"; eventually+it should say "need to".*++You should follow this process if you intend to make substantial changes to+Nushell, or this RFC process itself. What constitutes a substantial change is+evolving based on community norms and varies depending on what part of the+ecosystem you are proposing to change, but may include the following:++  - Any semantic or syntactic change that is not a bugfix.+  - Removing existing features.+  - Changes to internal interfaces, like the plugin architecture.++Some changes do not require an RFC:++  - Rephrasing, reorganizing, refactoring, or otherwise "changing shape does+    not change meaning".+  - Additions that strictly improve objective, numerical quality criteria+    (warning removal, speedup, better platform coverage, more parallelism,+    better handle errors, etc.)+  - Additions only likely to be _noticed by_ other developers of Nushell,+    invisible to users of Nushell.++If you submit a pull request to implement a new feature without going through+the RFC process, it may be closed with a polite request to submit an RFC first.+++## Before creating an RFC+[Before creating an RFC]: #before-creating-an-rfc+

I've dropped the entire first paragraph (no more mention of "hastily") and edited the others a bit.

jzaefferer

comment created time in a month

push eventjzaefferer/rfcs

Jörn Zaefferer

commit sha e5e236d148f0122042d6ad40c1471c3f4f172948

readme: add reference to TC39 process for future stages

view details

Jörn Zaefferer

commit sha fc9fb08a406a8b2d770176d686cced2750d1c2cf

readme: rework 'Before creating an RFC' Remove the gate-keeping language and instead focus on getting feedback up-front.

view details

push time in a month

Pull request review commentnushell/rfcs

propose RFC process (meta proposal)

+# Nushell RFCs++[Nushell RFCs]: #nushell-rfcs++Many changes, including bug fixes and documentation improvements can be+implemented and reviewed via the normal GitHub pull request workflow.++Though ssome changes are substantial enough that we ask for these to be+put through a bit of a design process and produce a consensus among the+Nushell community.++The "RFC" (request for comments) process is intended to provide a consistent+and controlled path for new features to be added to Nushell, so that all+stakeholders can be confident about the direction the project is evolving in.+++## Table of Contents+[Table of Contents]: #table-of-contents++  - [Opening](#nushell-rfcs)+  - [Table of Contents]+  - [When you need to follow this process]+  - [Before creating an RFC]+  - [What the process is]+  - [The RFC life-cycle]+  - [Reviewing RFCs]+  - [Implementing an RFC]+  - [RFC Postponement]+  - [Help this is all too informal!]+  - [License]+  - [Contributions]+  - [Acknowledgements]+++## When you should follow this process+[When you should follow this process]: #when-you-should-follow-this-process++*Note: While we establish this RFC process, this says "should"; eventually+it should say "need to".*++You should follow this process if you intend to make substantial changes to+Nushell, or this RFC process itself. What constitutes a substantial change is+evolving based on community norms and varies depending on what part of the+ecosystem you are proposing to change, but may include the following:++  - Any semantic or syntactic change that is not a bugfix.+  - Removing existing features.+  - Changes to internal interfaces, like the plugin architecture.++Some changes do not require an RFC:++  - Rephrasing, reorganizing, refactoring, or otherwise "changing shape does+    not change meaning".+  - Additions that strictly improve objective, numerical quality criteria+    (warning removal, speedup, better platform coverage, more parallelism,+    better handle errors, etc.)+  - Additions only likely to be _noticed by_ other developers of Nushell,+    invisible to users of Nushell.++If you submit a pull request to implement a new feature without going through+the RFC process, it may be closed with a polite request to submit an RFC first.+++## Before creating an RFC+[Before creating an RFC]: #before-creating-an-rfc+

Looking at https://github.com/emberjs/rfcs I don't see well-defined stages. It looks very similar to Rust's process.

Good points. Yes, agreed that "please come talk to us on discord" is probably the right first step :)

Its kinda in this section already, but a bit buried, and without mentioning the channel. I'll rework that.

jzaefferer

comment created time in a month

Pull request review commentnushell/rfcs

propose RFC process (meta proposal)

+# Nushell RFCs++[Nushell RFCs]: #nushell-rfcs++Many changes, including bug fixes and documentation improvements can be+implemented and reviewed via the normal GitHub pull request workflow.++Though ssome changes are substantial enough that we ask for these to be+put through a bit of a design process and produce a consensus among the+Nushell community.++The "RFC" (request for comments) process is intended to provide a consistent+and controlled path for new features to be added to Nushell, so that all+stakeholders can be confident about the direction the project is evolving in.+++## Table of Contents+[Table of Contents]: #table-of-contents++  - [Opening](#nushell-rfcs)+  - [Table of Contents]+  - [When you need to follow this process]+  - [Before creating an RFC]+  - [What the process is]+  - [The RFC life-cycle]+  - [Reviewing RFCs]+  - [Implementing an RFC]+  - [RFC Postponement]+  - [Help this is all too informal!]+  - [License]+  - [Contributions]+  - [Acknowledgements]+++## When you should follow this process+[When you should follow this process]: #when-you-should-follow-this-process++*Note: While we establish this RFC process, this says "should"; eventually+it should say "need to".*++You should follow this process if you intend to make substantial changes to+Nushell, or this RFC process itself. What constitutes a substantial change is+evolving based on community norms and varies depending on what part of the+ecosystem you are proposing to change, but may include the following:++  - Any semantic or syntactic change that is not a bugfix.+  - Removing existing features.+  - Changes to internal interfaces, like the plugin architecture.++Some changes do not require an RFC:++  - Rephrasing, reorganizing, refactoring, or otherwise "changing shape does+    not change meaning".+  - Additions that strictly improve objective, numerical quality criteria+    (warning removal, speedup, better platform coverage, more parallelism,+    better handle errors, etc.)+  - Additions only likely to be _noticed by_ other developers of Nushell,+    invisible to users of Nushell.++If you submit a pull request to implement a new feature without going through+the RFC process, it may be closed with a polite request to submit an RFC first.+++## Before creating an RFC+[Before creating an RFC]: #before-creating-an-rfc++A hastily-proposed RFC can hurt its chances of acceptance. Low quality+proposals, proposals for previously-rejected features, or those that don't fit+into the near-term roadmap, may be quickly rejected, which can be demotivating+for the unprepared contributor. Laying some groundwork ahead of the RFC can+make the process smoother.++Although there is no single way to prepare for submitting an RFC, it is+generally a good idea to pursue feedback from other project developers+beforehand, to ascertain that the RFC may be desirable; having a consistent+impact on the project requires concerted effort toward consensus-building.++The most common preparations for writing and submitting an RFC include talking+the idea over on our [official Discord server] (*maybe later, also a discussion+forum*). You may file issues on this repo for discussion, but these are+not as actively looked at by the team.++As a rule of thumb, receiving encouraging feedback from long-standing project+developers is a good indication that the RFC is worth pursuing.+++## What the process is+[What the process is]: #what-the-process-is++In short, to get a major feature added to Nushell, one must (for now: should)+first get the RFC merged into the RFC repository as a markdown file. At that+point the RFC is "active" and may be implemented with the goal of inclusion+into Nushell.++  - Fork the RFC repo [RFC repository]+  - Copy `0000-template.md` to `text/0000-my-feature.md` (where "my-feature" is+    descriptive. Leave the `0000` for now).+  - Fill in the RFC. Put care into the details: RFCs that do not present+    convincing motivation, demonstrate lack of understanding of the design's+    impact, or are disingenuous about the drawbacks or alternatives tend to+    be poorly-received.+  - Submit a pull request. As a pull request the RFC will receive design+    feedback from the larger community, and the author should be prepared to+    revise it in response.+  - Now that your RFC has an open pull request, use the issue number of the PR+    to update your `0000-` prefix to that number.+  - Where applicable, each pull request will be triaged by the team in a+    future meeting and assigned to a member of the team.+  - Build consensus and integrate feedback. RFCs that have broad support are+    much more likely to make progress than those that don't receive any+    comments. Feel free to reach out to the RFC assignee in particular to get+    help identifying stakeholders and obstacles.+  - The team will discuss the RFC pull request, as much as possible in the+    comment thread of the pull request itself. Other discussion (e.g. on+    Discord) will be summarized on the pull request comment thread.+  - RFCs rarely go through this process unchanged, especially as alternatives+    and drawbacks are shown. You can make edits, big and small, to the RFC to+    clarify or change the design, but make changes as new commits to the pull+    request, and leave a comment on the pull request explaining your changes.+    **Specifically, do not squash or rebase commits after they are visible on the+    pull request.**+  - At some point, a member of the team will propose a "motion for final+    comment period" (FCP), along with a *disposition* for the RFC (merge, close,+    or postpone).+    - This step is taken when enough of the tradeoffs have been discussed that+      the team is in a position to make a decision. That does not require+      consensus amongst all participants in the RFC thread (which is usually+      impossible). However, the argument supporting the disposition on the RFC+      needs to have already been clearly articulated, and there should not be a+      strong consensus *against* that position. Team members use their best+      judgment in taking this step, and the FCP itself ensures there is ample+      time and notification for stakeholders to push back if it is made+      prematurely.+    - For RFCs with lengthy discussion, the motion to FCP is usually preceded by+      a *summary comment* trying to lay out the current state of the discussion+      and major tradeoffs/points of disagreement.+    - Before actually entering FCP, *all* team members must sign off; this+      might be the point at which many team members first review the RFC in full+      depth.+  - The FCP lasts ten calendar days, so that it is open for at least 5 business+    days. It is also advertised widely,+    e.g. in [This Week in Nushell](https://www.notion.so/This-Week-in-Nu-ed589e19f1be47fa9ef562c1757e7ba1).+    This way all stakeholders have a chance to lodge any final objections+    before a decision is reached.+  - In most cases, the FCP period is quiet, and the RFC is either merged or+    closed. However, sometimes substantial new arguments or ideas are raised,+    the FCP is canceled, and the RFC goes back into development mode.++## The RFC life-cycle+[The RFC life-cycle]: #the-rfc-life-cycle++Once an RFC becomes "active" then authors may implement it and submit the+feature as a pull request to the Nushell repo. Being "active" is not a rubber+stamp, and in particular still does not mean the feature will ultimately be+merged; it does mean that in principle all the major stakeholders have agreed+to the feature and are amenable to merging it.++Furthermore, the fact that a given RFC has been accepted and is "active"+implies nothing about what priority is assigned to its implementation, nor does+it imply anything about whether a Nushell developer has been assigned the task of+implementing the feature. While it is not *necessary* that the author of the+RFC also write the implementation, it is by far the most effective way to see+an RFC through to completion: authors should not expect that other project+developers will take on responsibility for implementing their accepted feature.++Modifications to "active" RFCs can be done in follow-up pull requests. We+strive to write each RFC in a manner that it will reflect the final design of+the feature; but the nature of the process means that we cannot expect every+merged RFC to actually reflect what the end result will be at the time of the+next major release.++In general, once accepted, RFCs should not be substantially changed. Only very+minor changes should be submitted as amendments. More substantial changes+should be new RFCs, with a note added to the original RFC. Exactly what counts+as a "very minor change" is up to the team to decide.+++## Reviewing RFCs+[Reviewing RFCs]: #reviewing-rfcs++While the RFC pull request is up, the team may schedule meetings with the+author and/or relevant stakeholders to discuss the issues in greater detail,+and in some cases the topic may be discussed at a team meeting. In either+case a summary from the meeting will be posted back to the RFC pull request.++The team makes final decisions about RFCs after the benefits and drawbacks+are well understood. These decisions can be made at any time, but the team+will regularly issue decisions. When a decision is made, the RFC pull request+will either be merged or closed. In either case, if the reasoning is not clear+from the discussion in thread, the team will add a comment describing the+rationale for the decision.+++## Implementing an RFC+[Implementing an RFC]: #implementing-an-rfc++Some accepted RFCs represent vital features that need to be implemented right+away. Other accepted RFCs can represent features that can wait until some+arbitrary developer feels like doing the work. Every accepted RFC has an+associated issue tracking its implementation in the Nushell repository; thus that+associated issue can be assigned a priority via the triage process that the+team uses for all issues in the Nushell repository.++The author of an RFC is not obligated to implement it. Of course, the RFC+author (like any other developer) is welcome to post an implementation for+review after the RFC has been accepted.++If you are interested in working on the implementation for an "active" RFC, but+cannot determine if someone else is already working on it, feel free to ask+(e.g. by leaving a comment on the associated issue).+++## RFC Postponement+[RFC Postponement]: #rfc-postponement++Some RFC pull requests are tagged with the "postponed" label when they are+closed (as part of the rejection process). An RFC closed with "postponed" is+marked as such because we want neither to think about evaluating the proposal+nor about implementing the described feature until some time in the future, and+we believe that we can afford to wait until then to do so. This could be used+to postpone features until after 1.0. Postponed pull requests may be re-opened+when the time is right. We don't have any formal process for that.++Usually an RFC pull request marked as "postponed" has already passed an+informal first round of evaluation, namely the round of "do we think we would+ever possibly consider making this change, as outlined in the RFC pull request,+or some semi-obvious variation of it." (When the answer to the latter question+is "no", then the appropriate response is to close the RFC, not postpone it.)+++### Help this is all too informal!

Remove

jzaefferer

comment created time in a month

push eventjzaefferer/rfcs

Jörn Zaefferer

commit sha 34f9092ad2784377b719b2f09db3e1809fc38def

readme: remove 'Help this is all too informal' Not helpful, maybe condescending

view details

push time in a month

Pull request review commentnushell/rfcs

propose RFC process (meta proposal)

+# Nushell RFCs++[Nushell RFCs]: #nushell-rfcs++Many changes, including bug fixes and documentation improvements can be+implemented and reviewed via the normal GitHub pull request workflow.++Though ssome changes are substantial enough that we ask for these to be+put through a bit of a design process and produce a consensus among the+Nushell community.++The "RFC" (request for comments) process is intended to provide a consistent+and controlled path for new features to be added to Nushell, so that all+stakeholders can be confident about the direction the project is evolving in.+++## Table of Contents+[Table of Contents]: #table-of-contents++  - [Opening](#nushell-rfcs)+  - [Table of Contents]+  - [When you need to follow this process]+  - [Before creating an RFC]+  - [What the process is]+  - [The RFC life-cycle]+  - [Reviewing RFCs]+  - [Implementing an RFC]+  - [RFC Postponement]+  - [Help this is all too informal!]+  - [License]+  - [Contributions]+  - [Acknowledgements]+++## When you should follow this process+[When you should follow this process]: #when-you-should-follow-this-process++*Note: While we establish this RFC process, this says "should"; eventually+it should say "need to".*++You should follow this process if you intend to make substantial changes to+Nushell, or this RFC process itself. What constitutes a substantial change is+evolving based on community norms and varies depending on what part of the+ecosystem you are proposing to change, but may include the following:++  - Any semantic or syntactic change that is not a bugfix.+  - Removing existing features.+  - Changes to internal interfaces, like the plugin architecture.++Some changes do not require an RFC:++  - Rephrasing, reorganizing, refactoring, or otherwise "changing shape does+    not change meaning".+  - Additions that strictly improve objective, numerical quality criteria+    (warning removal, speedup, better platform coverage, more parallelism,+    better handle errors, etc.)+  - Additions only likely to be _noticed by_ other developers of Nushell,+    invisible to users of Nushell.++If you submit a pull request to implement a new feature without going through+the RFC process, it may be closed with a polite request to submit an RFC first.+++## Before creating an RFC+[Before creating an RFC]: #before-creating-an-rfc++A hastily-proposed RFC can hurt its chances of acceptance. Low quality+proposals, proposals for previously-rejected features, or those that don't fit+into the near-term roadmap, may be quickly rejected, which can be demotivating+for the unprepared contributor. Laying some groundwork ahead of the RFC can+make the process smoother.++Although there is no single way to prepare for submitting an RFC, it is+generally a good idea to pursue feedback from other project developers+beforehand, to ascertain that the RFC may be desirable; having a consistent+impact on the project requires concerted effort toward consensus-building.++The most common preparations for writing and submitting an RFC include talking+the idea over on our [official Discord server] (*maybe later, also a discussion+forum*). You may file issues on this repo for discussion, but these are+not as actively looked at by the team.++As a rule of thumb, receiving encouraging feedback from long-standing project+developers is a good indication that the RFC is worth pursuing.+++## What the process is+[What the process is]: #what-the-process-is++In short, to get a major feature added to Nushell, one must (for now: should)+first get the RFC merged into the RFC repository as a markdown file. At that+point the RFC is "active" and may be implemented with the goal of inclusion+into Nushell.++  - Fork the RFC repo [RFC repository]+  - Copy `0000-template.md` to `text/0000-my-feature.md` (where "my-feature" is+    descriptive. Leave the `0000` for now).+  - Fill in the RFC. Put care into the details: RFCs that do not present+    convincing motivation, demonstrate lack of understanding of the design's+    impact, or are disingenuous about the drawbacks or alternatives tend to+    be poorly-received.+  - Submit a pull request. As a pull request the RFC will receive design+    feedback from the larger community, and the author should be prepared to+    revise it in response.+  - Now that your RFC has an open pull request, use the issue number of the PR+    to update your `0000-` prefix to that number.+  - Where applicable, each pull request will be triaged by the team in a+    future meeting and assigned to a member of the team.+  - Build consensus and integrate feedback. RFCs that have broad support are+    much more likely to make progress than those that don't receive any+    comments. Feel free to reach out to the RFC assignee in particular to get+    help identifying stakeholders and obstacles.+  - The team will discuss the RFC pull request, as much as possible in the+    comment thread of the pull request itself. Other discussion (e.g. on+    Discord) will be summarized on the pull request comment thread.+  - RFCs rarely go through this process unchanged, especially as alternatives+    and drawbacks are shown. You can make edits, big and small, to the RFC to+    clarify or change the design, but make changes as new commits to the pull+    request, and leave a comment on the pull request explaining your changes.+    **Specifically, do not squash or rebase commits after they are visible on the+    pull request.**+  - At some point, a member of the team will propose a "motion for final+    comment period" (FCP), along with a *disposition* for the RFC (merge, close,+    or postpone).+    - This step is taken when enough of the tradeoffs have been discussed that+      the team is in a position to make a decision. That does not require+      consensus amongst all participants in the RFC thread (which is usually+      impossible). However, the argument supporting the disposition on the RFC+      needs to have already been clearly articulated, and there should not be a+      strong consensus *against* that position. Team members use their best+      judgment in taking this step, and the FCP itself ensures there is ample+      time and notification for stakeholders to push back if it is made+      prematurely.+    - For RFCs with lengthy discussion, the motion to FCP is usually preceded by+      a *summary comment* trying to lay out the current state of the discussion+      and major tradeoffs/points of disagreement.+    - Before actually entering FCP, *all* team members must sign off; this+      might be the point at which many team members first review the RFC in full+      depth.+  - The FCP lasts ten calendar days, so that it is open for at least 5 business+    days. It is also advertised widely,+    e.g. in [This Week in Nushell](https://www.notion.so/This-Week-in-Nu-ed589e19f1be47fa9ef562c1757e7ba1).+    This way all stakeholders have a chance to lodge any final objections+    before a decision is reached.+  - In most cases, the FCP period is quiet, and the RFC is either merged or+    closed. However, sometimes substantial new arguments or ideas are raised,+    the FCP is canceled, and the RFC goes back into development mode.++## The RFC life-cycle+[The RFC life-cycle]: #the-rfc-life-cycle++Once an RFC becomes "active" then authors may implement it and submit the+feature as a pull request to the Nushell repo. Being "active" is not a rubber+stamp, and in particular still does not mean the feature will ultimately be+merged; it does mean that in principle all the major stakeholders have agreed+to the feature and are amenable to merging it.

That's good feedback. How about we lower the requirements for accepting an RFC, for now? That can still be adjusted later.

For example, we could do this:

- - Before actually entering FCP, *all* team members must sign off;
+ - Before actually entering FCP, *at least two* team members must sign off;
jzaefferer

comment created time in a month

Pull request review commentnushell/rfcs

propose RFC process (meta proposal)

+# Nushell RFCs++[Nushell RFCs]: #nushell-rfcs++Many changes, including bug fixes and documentation improvements can be+implemented and reviewed via the normal GitHub pull request workflow.++Though ssome changes are substantial enough that we ask for these to be+put through a bit of a design process and produce a consensus among the+Nushell community.++The "RFC" (request for comments) process is intended to provide a consistent+and controlled path for new features to be added to Nushell, so that all+stakeholders can be confident about the direction the project is evolving in.+++## Table of Contents+[Table of Contents]: #table-of-contents++  - [Opening](#nushell-rfcs)+  - [Table of Contents]+  - [When you need to follow this process]+  - [Before creating an RFC]+  - [What the process is]+  - [The RFC life-cycle]+  - [Reviewing RFCs]+  - [Implementing an RFC]+  - [RFC Postponement]+  - [Help this is all too informal!]+  - [License]+  - [Contributions]+  - [Acknowledgements]+++## When you should follow this process+[When you should follow this process]: #when-you-should-follow-this-process++*Note: While we establish this RFC process, this says "should"; eventually+it should say "need to".*++You should follow this process if you intend to make substantial changes to+Nushell, or this RFC process itself. What constitutes a substantial change is+evolving based on community norms and varies depending on what part of the+ecosystem you are proposing to change, but may include the following:++  - Any semantic or syntactic change that is not a bugfix.+  - Removing existing features.+  - Changes to internal interfaces, like the plugin architecture.++Some changes do not require an RFC:++  - Rephrasing, reorganizing, refactoring, or otherwise "changing shape does+    not change meaning".+  - Additions that strictly improve objective, numerical quality criteria+    (warning removal, speedup, better platform coverage, more parallelism,+    better handle errors, etc.)+  - Additions only likely to be _noticed by_ other developers of Nushell,+    invisible to users of Nushell.++If you submit a pull request to implement a new feature without going through+the RFC process, it may be closed with a polite request to submit an RFC first.+++## Before creating an RFC+[Before creating an RFC]: #before-creating-an-rfc+

One possible thing we should talk about is to help direct people towards mentors [...]

Given the current state, effectively that would mean "chat with us on Discord in #design-discussion", wouldn't it?

If not, could you go into more detail?

[stages]

Do you have something like the TC39 stages in mind? https://tc39.es/process-document/ At least I think those could be a good reference.

I don't think we should start with that, though. I'd rather leave it open to adopt stages like that later.

We can replace some of the language here, like "hastily" and make "strawperson" (from TC39) RFCs more welcome.

jzaefferer

comment created time in a month

push eventjzaefferer/rfcs

Jörn Zaefferer

commit sha fd010063aebf6d90767c8112c8c60f09e47d24cf

readme: fix word order Co-authored-by: Enes Fazli <fazli.enes@gmail.com>

view details

push time in a month

push eventjzaefferer/rfcs

Jörn Zaefferer

commit sha 506f7621ed48a4bab99ab1e2c996b0cfd70c9882

readme: fix typo Co-authored-by: Enes Fazli <fazli.enes@gmail.com>

view details

push time in a month

Pull request review commentnushell/rfcs

propose RFC process (meta proposal)

+# Nushell RFCs++[Nushell RFCs]: #nushell-rfcs++Many changes, including bug fixes and documentation improvements can be+implemented and reviewed via the normal GitHub pull request workflow.++Though ssome changes are substantial enough that we ask for these to be+put through a bit of a design process and produce a consensus among the+Nushell community.++The "RFC" (request for comments) process is intended to provide a consistent+and controlled path for new features to be added to Nushell, so that all+stakeholders can be confident about the direction the project is evolving in.+++## Table of Contents+[Table of Contents]: #table-of-contents++  - [Opening](#nushell-rfcs)+  - [Table of Contents]+  - [When you need to follow this process]+  - [Before creating an RFC]+  - [What the process is]+  - [The RFC life-cycle]+  - [Reviewing RFCs]+  - [Implementing an RFC]+  - [RFC Postponement]+  - [Help this is all too informal!]+  - [License]+  - [Contributions]+  - [Acknowledgements]+++## When you should follow this process+[When you should follow this process]: #when-you-should-follow-this-process++*Note: While we establish this RFC process, this says "should"; eventually+it should say "need to".*++You should follow this process if you intend to make substantial changes to+Nushell, or this RFC process itself. What constitutes a substantial change is+evolving based on community norms and varies depending on what part of the+ecosystem you are proposing to change, but may include the following:++  - Any semantic or syntactic change that is not a bugfix.+  - Removing existing features.+  - Changes to internal interfaces, like the plugin architecture.++Some changes do not require an RFC:++  - Rephrasing, reorganizing, refactoring, or otherwise "changing shape does+    not change meaning".+  - Additions that strictly improve objective, numerical quality criteria+    (warning removal, speedup, better platform coverage, more parallelism,+    better handle errors, etc.)+  - Additions only likely to be _noticed by_ other developers of Nushell,+    invisible to users of Nushell.++If you submit a pull request to implement a new feature without going through+the RFC process, it may be closed with a polite request to submit an RFC first.+++## Before creating an RFC+[Before creating an RFC]: #before-creating-an-rfc++A hastily-proposed RFC can hurt its chances of acceptance. Low quality+proposals, proposals for previously-rejected features, or those that don't fit+into the near-term roadmap, may be quickly rejected, which can be demotivating+for the unprepared contributor. Laying some groundwork ahead of the RFC can+make the process smoother.++Although there is no single way to prepare for submitting an RFC, it is+generally a good idea to pursue feedback from other project developers+beforehand, to ascertain that the RFC may be desirable; having a consistent+impact on the project requires concerted effort toward consensus-building.++The most common preparations for writing and submitting an RFC include talking+the idea over on our [official Discord server] (*maybe later, also a discussion+forum*). You may file issues on this repo for discussion, but these are+not as actively looked at by the team.++As a rule of thumb, receiving encouraging feedback from long-standing project+developers is a good indication that the RFC is worth pursuing.+++## What the process is+[What the process is]: #what-the-process-is++In short, to get a major feature added to Nushell, one must (for now: should)+first get the RFC merged into the RFC repository as a markdown file. At that+point the RFC is "active" and may be implemented with the goal of inclusion+into Nushell.++  - Fork the RFC repo [RFC repository]+  - Copy `0000-template.md` to `text/0000-my-feature.md` (where "my-feature" is+    descriptive. Leave the `0000` for now).+  - Fill in the RFC. Put care into the details: RFCs that do not present+    convincing motivation, demonstrate lack of understanding of the design's+    impact, or are disingenuous about the drawbacks or alternatives tend to+    be poorly-received.+  - Submit a pull request. As a pull request the RFC will receive design+    feedback from the larger community, and the author should be prepared to+    revise it in response.+  - Now that your RFC has an open pull request, use the issue number of the PR+    to update your `0000-` prefix to that number.+  - Where applicable, each pull request will be triaged by the team in a+    future meeting and assigned to a member of the team.+  - Build consensus and integrate feedback. RFCs that have broad support are+    much more likely to make progress than those that don't receive any+    comments. Feel free to reach out to the RFC assignee in particular to get+    help identifying stakeholders and obstacles.+  - The team will discuss the RFC pull request, as much as possible in the+    comment thread of the pull request itself. Other discussion (e.g. on+    Discord) will be summarized on the pull request comment thread.+  - RFCs rarely go through this process unchanged, especially as alternatives+    and drawbacks are shown. You can make edits, big and small, to the RFC to+    clarify or change the design, but make changes as new commits to the pull+    request, and leave a comment on the pull request explaining your changes.+    **Specifically, do not squash or rebase commits after they are visible on the+    pull request.**+  - At some point, a member of the team will propose a "motion for final+    comment period" (FCP), along with a *disposition* for the RFC (merge, close,+    or postpone).+    - This step is taken when enough of the tradeoffs have been discussed that+      the team is in a position to make a decision. That does not require+      consensus amongst all participants in the RFC thread (which is usually+      impossible). However, the argument supporting the disposition on the RFC+      needs to have already been clearly articulated, and there should not be a+      strong consensus *against* that position. Team members use their best+      judgment in taking this step, and the FCP itself ensures there is ample+      time and notification for stakeholders to push back if it is made+      prematurely.+    - For RFCs with lengthy discussion, the motion to FCP is usually preceded by+      a *summary comment* trying to lay out the current state of the discussion+      and major tradeoffs/points of disagreement.+    - Before actually entering FCP, *all* team members must sign off; this+      might be the point at which many team members first review the RFC in full+      depth.+  - The FCP lasts ten calendar days, so that it is open for at least 5 business+    days. It is also advertised widely,+    e.g. in [This Week in Nushell](https://www.notion.so/This-Week-in-Nu-ed589e19f1be47fa9ef562c1757e7ba1).+    This way all stakeholders have a chance to lodge any final objections+    before a decision is reached.+  - In most cases, the FCP period is quiet, and the RFC is either merged or+    closed. However, sometimes substantial new arguments or ideas are raised,+    the FCP is canceled, and the RFC goes back into development mode.++## The RFC life-cycle+[The RFC life-cycle]: #the-rfc-life-cycle++Once an RFC becomes "active" then authors may implement it and submit the+feature as a pull request to the Nushell repo. Being "active" is not a rubber+stamp, and in particular still does not mean the feature will ultimately be+merged; it does mean that in principle all the major stakeholders have agreed+to the feature and are amenable to merging it.++Furthermore, the fact that a given RFC has been accepted and is "active"+implies nothing about what priority is assigned to its implementation, nor does+it imply anything about whether a Nushell developer has been assigned the task of+implementing the feature. While it is not *necessary* that the author of the+RFC also write the implementation, it is by far the most effective way to see+an RFC through to completion: authors should not expect that other project+developers will take on responsibility for implementing their accepted feature.++Modifications to "active" RFCs can be done in follow-up pull requests. We+strive to write each RFC in a manner that it will reflect the final design of+the feature; but the nature of the process means that we cannot expect every+merged RFC to actually reflect what the end result will be at the time of the+next major release.++In general, once accepted, RFCs should not be substantially changed. Only very+minor changes should be submitted as amendments. More substantial changes+should be new RFCs, with a note added to the original RFC. Exactly what counts+as a "very minor change" is up to the team to decide.+++## Reviewing RFCs+[Reviewing RFCs]: #reviewing-rfcs++While the RFC pull request is up, the team may schedule meetings with the+author and/or relevant stakeholders to discuss the issues in greater detail,+and in some cases the topic may be discussed at a team meeting. In either+case a summary from the meeting will be posted back to the RFC pull request.++The team makes final decisions about RFCs after the benefits and drawbacks+are well understood. These decisions can be made at any time, but the team+will regularly issue decisions. When a decision is made, the RFC pull request+will either be merged or closed. In either case, if the reasoning is not clear+from the discussion in thread, the team will add a comment describing the+rationale for the decision.+++## Implementing an RFC+[Implementing an RFC]: #implementing-an-rfc++Some accepted RFCs represent vital features that need to be implemented right+away. Other accepted RFCs can represent features that can wait until some+arbitrary developer feels like doing the work. Every accepted RFC has an+associated issue tracking its implementation in the Nushell repository; thus that+associated issue can be assigned a priority via the triage process that the+team uses for all issues in the Nushell repository.++The author of an RFC is not obligated to implement it. Of course, the RFC+author (like any other developer) is welcome to post an implementation for+review after the RFC has been accepted.++If you are interested in working on the implementation for an "active" RFC, but+cannot determine if someone else is already working on it, feel free to ask+(e.g. by leaving a comment on the associated issue).+++## RFC Postponement+[RFC Postponement]: #rfc-postponement++Some RFC pull requests are tagged with the "postponed" label when they are+closed (as part of the rejection process). An RFC closed with "postponed" is+marked as such because we want neither to think about evaluating the proposal+nor about implementing the described feature until some time in the future, and+we believe that we can afford to wait until then to do so. This could be used+to postpone features until after 1.0. Postponed pull requests may be re-opened+when the time is right. We don't have any formal process for that.++Usually an RFC pull request marked as "postponed" has already passed an+informal first round of evaluation, namely the round of "do we think we would+ever possibly consider making this change, as outlined in the RFC pull request,+or some semi-obvious variation of it." (When the answer to the latter question+is "no", then the appropriate response is to close the RFC, not postpone it.)+++### Help this is all too informal!

I agree with you, let's drop it.

jzaefferer

comment created time in a month

PR opened rust-lang/rfcs

Readme fixes

This PR provides a few small fixes for the README:

  • move global links to the end of the document
  • clarify how the 0000 gets replaced with the PR issue number
  • use https for all links
  • adding missing ToC entries

For "clarify how the 0000 gets replaced with the PR issue number" I looked at how the rename was made in practice, since I couldn't find any instruction for it. I hope this captures it well enough.

I noticed these while adopting this RFC process for Nushell, under the MIT License: https://github.com/nushell/rfcs/pull/1 I've added an Acknowledgements section to reflect the copy we started with. If there's a problem with this approach, please let us know.

+15 -8

0 comment

1 changed file

pr created time in a month

create barnchjzaefferer/rfcs-1

branch : readme-fixes

created branch time in a month

PR opened nushell/rfcs

propose RFC process (meta proposal)

As discussed on Discord, I've copied parts of Rust's RFC process and adapted it to Nushell. Changing the template was pretty easy, changing the README was much much more work. Accordingly I expect that to need a much more thorough review.

Diffing against the original might help; I could add that as a gist later.

I noticed a few small issues in the original README and will submit that as a PR to their repo.

+405 -0

0 comment

3 changed files

pr created time in a month

create barnchjzaefferer/rfcs

branch : initial

created branch time in a month

fork jzaefferer/rfcs

Request For Comment (RFC) repo for Nu

fork in a month

issue commentgetsentry/sentry

Filter out "Network request failed" errors

I agree but even to send an error like Sentry.captureException(new Error('test')) would fail when there is no internet connection and crashes the app.

At least in the browser the errors seem to be batched and send later, otherwise they would never shop up in Sentry.

fabb

comment created time in a month

issue commentJedWatson/react-select

Support for Chrome autofill

Yes, I feel like this is still relevant. I helped implement the original PR for this, @mmintel was a coworker.

casschin

comment created time in a month

issue openedSonarSource/eslint-plugin-sonarjs

Indicate which rules are part of the preset, and which aren't

I want to request a feature.

The readme lists all the available rules (yay), but gives no indication which of those are part of the recommended preset, and which aren't. Since I'd like to check out the others rules, I'm looking for a list of the rules outside the preset. Which I can't find so far.

I suspect that the recommended preset is created here, but I haven't yet figured out what's actually happening: https://github.com/SonarSource/eslint-plugin-sonarjs/blob/master/src/index.ts

Here's an example of a table of rules from a different plugin that indicate which rules are included in which preset: https://github.com/testing-library/eslint-plugin-testing-library#supported-rules - this is really nice!

Here's another example, which only lists the rules in the preset, separate from the main list of rules: https://github.com/yannickcr/eslint-plugin-react#recommended - still better than nothing, but requires more effort to identify the not-in-the-preset rules.

created time in a month

Pull request review commentnushell/nushell

docs: add alias --save flag

 # alias-This command allows you to define shortcuts for other common commands.+This command allows you to define shortcuts for other common commands. By default, they only apply to the current session. To persist them, add `--save`.++Syntax: `alias {flags} <name> [<parameters] {<body>}`

Good catch, good fix

jzaefferer

comment created time in a month

issue commentnushell/nushell

Need to document `no_auto_pivot`

@thegedge since you added that checklist - where in 'Nushell' should this get documented?

help config doesn't have a list of available config variables - maybe that's the part that's missing?

jonathandturner

comment created time in a month

PR opened nushell/book

aliases can be --save(ed)
+17 -3

0 comment

2 changed files

pr created time in a month

push eventjzaefferer/book

Jörn Zaefferer

commit sha d62435a8274e5872432bb6cc3e1e2001ffb49945

aliases can be --save(ed)

view details

push time in a month

create barnchjzaefferer/book

branch : aliases-save

created branch time in a month

push eventjzaefferer/book

Ricardo Yepes

commit sha a2bf035cf1eccaaa6d0c6666bdae38604f7470c6

Commands: from - take

view details

Ricardo Yepes

commit sha 2d39675475ad63fd55ddf2004b3b5fd269a57d82

Finished 90% of mappings for Python, Kotlin, C++, Rust, C#, Clojure, Ocaml / Elm and Haskell

view details

Ricardo Yepes

commit sha 895c7868131498b749f26b7f2bfb974929dd467c

Merge 0.14.1 changes

view details

Ricardo Yepes

commit sha 83f116780c7e21dd3ec0389e329560fc769142ad

Compact to and from commands in tables

view details

Ricardo Yepes

commit sha a2d4910cde6ef5ed7c9da4fd82693d1d061ede98

Haskell sum

view details

Ricardo Yepes

commit sha 222e6e838c4d54df052141f7946f109df3a3036e

Latest mapping tables cleanup

view details

Andrés N. Robalino

commit sha de12fc31a175e52aa96806fe0029da9b22060cc1

Math, Aliases, Environment additions + overll minor fixes.

view details

Andrés N. Robalino

commit sha 63f368317f412d14b4337b1a3dc9ac329b5e8882

comma when using in: operator is still not treated as whitespace.

view details

Andrés N. Robalino

commit sha 27cc61b338045c0b5299a0e6b23813f10b0e8a91

Merge pull request #95 from andrasio/mas-capitulos Math, Aliases, Environment additions + overll minor fixes.

view details

Samuel Wehunt

commit sha bb6c1a85a948b568d097a1ae2a6ff063a3bc8015

added documentation for no_auto_pivot

view details

Jason Gedge

commit sha 458a773bd76e318aa987af767a1c421c71240bab

Merge pull request #96 from Samboy218/issue-1826

view details

zombie110year

commit sha acce64b1853068bd3fe2ec1ffb41767857cad4db

translate(en->zh-cn): installation

view details

zombie110year

commit sha 80d02fd3b32f5f80c036839de669d0b61f2a1ab4

translate(en->zh-cn): introduction

view details

Jonathan Turner

commit sha 7e38749c866ad5bbf2eaa2a7528bd7d5e553eab8

Merge branch 'master' into master

view details

Jonathan Turner

commit sha 85305f972bad9de46f3ae7dbfde90d2ab76c36f7

Merge pull request #93 from ryepesg/master Finishing mappings for functional and imperative languages

view details

zombie110year

commit sha 3b170213013d8038d71d02fece04e033b6e895f5

translate(en->zh-cn): moving around

view details

zombie110year

commit sha 42a2280d80445585c6b7ed38e629d00facd9d789

translate(en->zh-cn): types of data

view details

zombie110year

commit sha 247480e2e581a700baaac6518aac3b8a87c5bda2

update TOC

view details

mhmdanas

commit sha 932c8527603ef96926fd37f4f6190f4b1e1474dd

Use includes for code blocks in en/installation.md

view details

Jonathan Turner

commit sha 5780b64ad3a7b7e02f8e6247fd626807cb91893a

Merge pull request #97 from zombie110year/master translate(en->zh-cn): installation, introduction

view details

push time in a month

PR opened nushell/nushell

docs: add alias --save flag
+7 -1

0 comment

1 changed file

pr created time in a month

create barnchjzaefferer/nushell

branch : alias-save-docs

created branch time in a month

push eventjzaefferer/nushell

Jonathan Turner

commit sha 8a9fc6a7211206cb6491a3662026f047ee9a67ea

Fix changing to a new Windows drive (#1721) * Fix changing to a new Windows drive * Update cli.rs

view details

Jonathan Turner

commit sha 7ce8026916df5745dfc1b4c32fed4e61a09e597a

Ignore empty arguments passed to externals (#1722)

view details

Jason Gedge

commit sha 27fdef54790d28a9c878a213020d25d324220cad

Read exit status before failing in failed read from stdout pipe (#1723)

view details

Andrés N. Robalino

commit sha c3efdf2689b0bea169a88e65c419045be889cd9b

Rename edit command to update. (#1724) Rename edit command to update.

view details

Andrés N. Robalino

commit sha 96e5fc05a37bbd632867219b18fb85ecbb37f683

Pick->Select rename. Integration tests changes. (#1725) Pick->Select rename. Integration tests changes.

view details

Andrés N. Robalino

commit sha 180c1204f3870a48459dd72dac96136fa85eb23b

Use playground instead of depending on fixture format files. (#1726)

view details

Sean Hellum

commit sha e04b89f7478a0af431cd264cafa97ea881c8254b

[Gitpod] Refactor Gitpod configuration and add full Debugging support (#1728)

view details

Elton Leander Pinto

commit sha 9a94b3c6563a08bac19cfc7e4f9ac04f821ae65d

`start` command in nushell (#1727) * mvp for start command * modified the signature of the start command * parse filenames * working model for macos is done * refactored to read from pipes * start command works well on macos; manual testing reveals need of --args flag support * implemented start error; color printing of warning and errors * ran clippy and fixed warnings * fix a clippy lint that was caught in pipeline * fix dead code clippy lint for windows * add cfg annotation to import

view details

Andrés N. Robalino

commit sha f93ff9ec33eac200da25afc57165f40752d1d936

Make grouping more flexible. (#1741)

view details

chrisr

commit sha 55374ee54f7f3b874bda0e11ed385bf193e14ddb

Fix help text for alias command. (#1742) * Fix help text for alias command. * Rust fmt

view details

Elton Leander Pinto

commit sha ccd5d69fd1df8218ade363052ff9d3012d7da664

Bug fix start (#1738) * fix bug on linux; added start to the stable list * add to stable and fix clippy lint

view details

Jonathan Turner

commit sha 0f0847e45b8dbede4b484a233e557ff9c630752d

Move 'start' to use ShellError (#1743) * Move 'start' to use ShellError * Remove unnecessary changes * Add missing macOS change * Add default * More fixed * More fixed

view details

Joseph T. Lyons

commit sha f5e03aaf1c67c2a2b06cf863ce47b0a49c1809d8

Add cal command (#1739) * Add cal command * Fix docmentation to show commands on two lines * Use bullet points on flag documentation for cal * Dereference day before calling string method * Silence Clippy warning regarding a function with too many arguments * Update cal flag descriptions and documentation * Add some tests for the cal command

view details

Joseph T. Lyons

commit sha f702aae72fd4d218ead1bd639d99b999198fef3b

Don't include year and month by default, adds an option to display th… (#1745) * Don't include year and month by default, adds an option to display the quarters of the year * Add a test for cal that checks that year requested is in the return * rustfmt the cal tests

view details

Joseph T. Lyons

commit sha 8951a01e58ba1f98752349bce2c6093d9d7a37c0

update cal documentation (#1746)

view details

Jonathan Turner

commit sha a2e9bbd3587508e8c8e6ae0f2ac24a5f2dcb295d

Improve duration math and printing (#1748) * Improve duration math and printing * Fix test

view details

Jonathan Turner

commit sha 42eb658c37c7d6d6c92be37c927e62445260caa6

Add a simplified list view (#1749)

view details

Elichai Turkel

commit sha c3a066eeb4b0d7576388c5656a11a928725d517f

Add examples to commands (#1752) * Pass &dyn WholeStreamCommand to get_help * Add an optional example to the WholeStreamCommand trait * Add an example to the alias command

view details

Jonathan Turner

commit sha 2275575575ea17d9428ec98f90b38751eea34d01

Improve list view and ranges (#1753)

view details

Jonathan Turner

commit sha c5ea4a31bdd38b06f3c27a697de3b6768194cb0f

Adding coloring to help examples (#1754)

view details

push time in a month

issue commentnushell/book

Translations should use the exact same commands and outputs

For the sharing/reusing, I'm sure Jekyll has some feature. So the process could be: Extract a code example from the English intro into a separate file, include it in the English version, and use it for the translations.

Since nu itself is only in English (right?), the code examples could go into a new folder in the project root. Maybe "snippets"?

mhmdanas

comment created time in a month

issue commentnushell/book

Translations should use the exact same commands and outputs

I think this is mostly an issue of the english intro being up-to-date, and the translations still needing the same updates.

Would you like to help out with that? See https://github.com/nushell/book/pull/77 for the PR that updated the english introduction.

mhmdanas

comment created time in a month

pull request commentnushell/nushell

Allow user to specify the indentation setting on the pretty flag for the to json command

Maybe follow the JSON.stringify API in JavaScript here? Make the argument a string, so that you can also specify tabs or any other combination

JosephTLyons

comment created time in a month

issue commentnushell/nushell

Documentation for Nu commands (NO programming experience needed)

comparing docs/commands/ and crates/nu-cli/src/commands/, these 32 commands are still missing docs:

autoview,binaryview,clear,cp,describe,drop,each,empty?,keep,keep-until,keep-while,kill,match,merge,mkdir,mv,n,p,parse,post,pwd,range,rm,run_external,shuffle,skip-until,split-by,table,textview,touch,tree,with-env

Some to and from subcommands as well as plugins are probably missing, too; haven't checked those.

andrasio

comment created time in a month

PR opened nushell/nushell

add docs for start command
+26 -0

0 comment

1 changed file

pr created time in a month

create barnchjzaefferer/nushell

branch : docs-commands-start

created branch time in a month

push eventjzaefferer/book

Jörn Zaefferer

commit sha 6820fcd9e950feb5560545fdeb00e3ad76709ada

Add CONTRIBUTING.md with local Docker setup Getting jekyll running locally requires a working Ruby env, so avoid that by adding a docker-compose.yml that will run `jekyll serve` locally. Fixes #69

view details

Jörn Zaefferer

commit sha e1f6ab1319352d5ca082480283e51657a50df4a7

configuration: add startup variable I'm guessing the type and description based on the 0.13.0 release blog post: https://www.nushell.sh/blog/2020/04/21/nushell_0_13_0.html#startup-commands-jonathandturner

view details

Jörn Zaefferer

commit sha df6dc1b30fd9bcef057d47da29063d0fd5ece9db

coming_from_bash: add/edit alias in 4 variations

view details

Jörn Zaefferer

commit sha 8e4cd37275a7ffcb8df929a976540bf8d91c2300

contributing: add instructions for bundler Use port 4000 for both variants

view details

Jason Gedge

commit sha 75616b9bc181cd94767ea3f7de2715328e668c82

Merge pull request #70 from jzaefferer/contributing-md-with-local-docker-69

view details

Jonathan Turner

commit sha fadb5ca61cd89a68e47a7beb543ea0488509e370

Update configuration.md

view details

Jonathan Turner

commit sha 89a06bddecbcbd05f8c6af7588482bfa4e631949

Merge pull request #73 from jzaefferer/configuration-startup configuration: add startup variable

view details

Jonathan Turner

commit sha ed5f491f870c837b37395eea5f7c06464e36c166

Merge pull request #72 from jzaefferer/coming-from-bash-add-alias coming_from_bash: add alias in 4 variations

view details

Jörn Zaefferer

commit sha 500f6c61d330a2257aed1c901e801cdad67b4dfd

configuration: remove superflous 'on'

view details

Jörn Zaefferer

commit sha 27951fbcc0cc9affed773e21d2533c0899a17bb0

coming from bash: touch was added Removing the `| save <filename.ext>` line since there's no match in bash (accordingly the Bash cell is empty). That's pointless in this context - `save` is documented elsewhere.

view details

Jonathan Turner

commit sha 73663131d92b358f3c5341485ced3dd5b5360713

Merge pull request #71 from jzaefferer/coming-from-bash-touch-examples coming from bash: touch equivalent is (now) possible

view details

Jonathan Turner

commit sha c2b766bf9b0a2c41cc1ad6310ac0330f297c36bd

Merge pull request #74 from jzaefferer/config-typo configuration: remove superflous 'on'

view details

notryanb@gmail.com

commit sha f1f3364db36a79aece7f60c8f0d6e66c817ea3cf

fix typo in english installation instructions

view details

Jason Gedge

commit sha e7b99cf2094b4f72cc4a59046beb46215cf8eafb

Merge pull request #75 from notryanb/fix-build-src-typo

view details

Jörn Zaefferer

commit sha f6b4fa3589dace03edc6dddb2ffb4cb421fd57c7

update introduction to latest nu Fixes #68

view details

Jonathan Turner

commit sha 88e9d3bdf7d5e976bc1aa41faf4d4c52e3ca10d6

Update coming_from_bash.md

view details

Jonathan Turner

commit sha 8b8434fcd8bc433c832fe497281bbfe23f7d6c3c

Update coming_from_bash.md

view details

Jonathan Turner

commit sha 19b08720f28bc266bdda322ec7fc9bddb20cccac

Update coming_from_bash.md

view details

Darren Schroeder

commit sha 77034b9a21adb603c0134168ab2e6b1db393fd30

Added command map and operator map.

view details

Jonathan Turner

commit sha 509fd3af5b8b04dfbcbdea58d5e1332134177e2f

Merge pull request #79 from fdncred/master Added command map and operator map.

view details

push time in a month

issue commentTrueCar/react-launch-darkly

XMLHttpRequest failure: synchronous XHR request during page dismissal

@sethbattin looks like ldclient-js is deprecated and hasn't been updated in over a year. The replacement is launchdarkly-js-client-sdk. I could install that, but I don't think that would fulfill the peer-dependency of react-launch-darkly.

Maybe update to 4.2.0 with a proper npm release, replacing ldclient-js with launchdarkly-js-client-sdk?

Dnguye92

comment created time in 2 months

issue commentnushell/nushell

Command for opening files (and URLs) in their app

#1727 added the command as a plugin. It's missing documentation though.

Do plugin commands also get documented via docs/commands?

jzaefferer

comment created time in 2 months

pull request commentnushell/book

Added command map and operator map.

About testing: There's a recently added CONTRIBUTING.md with instructions for starting Jekyll natively or with Docker

fdncred

comment created time in 2 months

push eventjzaefferer/nushell

Jonathan Turner

commit sha 454f560eaa2980313c3adba9dfcf7e2b351848c6

Properly deserialize history args (#1710)

view details

Jörn Zaefferer

commit sha 3201c9064706401385df607b8d0556aee2c85056

Extend to/from usage text to indicate subcommands (#1711) Both to and from without a subcommand only print the helptext. Expand the usage line a bit, so a glance at `help commands` indicates the existance of the subcommands and mentions some common formats. Ref a9968046ede45827dfa1986f00059179e40b2c18 Ref #1708

view details

Jörn Zaefferer

commit sha 8ab2b924050d6e773b5d31a958d299a36f2df659

docs/commands: add from.md, update subcommands (#1712) This adds a top-level document for the new `from` command, with a list of links of all the subcommands. All the from-* subcommands keep their filename, but the content is updated to use the new subcommand syntax. Needs matching update for to* Ref #1709

view details

Jörn Zaefferer

commit sha 22e70478a42aee7848ce02c735dc5f81411e41a8

docs/commands: add to.md, update subcommands (#1715) This adds a top-level document for the new `to` command, with a list (of links) of all the subcommands. All the to-* subcommands keep their filename, but the content is updated to use the new subcommand syntax. Since not all subcommands have documentation, some items in the list are just text without a link. Also filled the list for the undocumented from* commands in the same style. Fixes #1709

view details

Jonathan Turner

commit sha b37e420c7c10d8c5b83b31a7266740630478480b

Add with-env command (#1717)

view details

Jonathan Turner

commit sha c06a6927093825064001c1b0ce4c135bd08127a5

Bash-like shorthand with-env (#1718) * Bash-like shorthand with-env * fix clippy warning

view details

push time in 2 months

pull request commentnushell/book

update introduction to latest nu

Something weird is going on here:

Screen Shot 2020-05-06 at 13 56 02

There's two spaces rendered after the #, indicated by the gray centered dots. Yet those are missing around the "pipe" between the 0 and 404.html. No (regular) spaces around type, but they exist on the left side of the previous pipe.

Seems like there's a mix of whitespace character in use, and some (html) renderers mess those up.

jzaefferer

comment created time in 2 months

pull request commentnushell/book

update introduction to latest nu

Are you copying from what Nu outputs? I wonder where it might be coming from

@jonathandturner yeah, I copied the nu output from iTerm2 and pasted it in VS Code in the markdown file. There it still looks fine.

I think monospace is not sufficient for proper box drawing. It's just the fallback font.

As far as I can tell, in the browser its being rendered with Consolas - that's available on my machine.

PS: nu's own markdown renderer (open en/introduction.md | save intro.html) doesn't convert the code blocks, so that test is useless

jzaefferer

comment created time in 2 months

PR opened nushell/book

update introduction to latest nu

Fixes #68

Somehow the rendered markdown is worse, which I don't understand:

Screen Shot 2020-05-05 at 21 30 06

In my editor its fine, in my editors' markdown preview its fine, but when rendered by Jekyll (or here in the GitHub diff), the header row doesn't align with the rest anymore.

Any idea what's going on there?

+88 -75

0 comment

1 changed file

pr created time in 2 months

push eventjzaefferer/book

Jörn Zaefferer

commit sha f6b4fa3589dace03edc6dddb2ffb4cb421fd57c7

update introduction to latest nu Fixes #68

view details

push time in 2 months

create barnchjzaefferer/book

branch : introduction-update

created branch time in 2 months

issue commentnushell/nushell

Ideas for Consistency

A "coming from sql" chapter sounds pretty good! The table is a great start for that already.

The one thing that sticks out is pick. I wonder if that really should be renamed to select.

fdncred

comment created time in 2 months

issue commentnushell/nushell

Feature request: Support for git

What I'm missing are the bash completions for git. The arrow-right completion at least helps with previous commands, but lots of others are missing.

I guess that's part of #1412 already.

techthumb

comment created time in 2 months

issue openednushell/book

Clarify list/objects vs rows/columns, with named vs unnamed (<value>) columns

❯ echo "[1, 2]" | from json
───┬─────────
 # │ <value> 
───┼─────────
 0 │       1 
 1 │       2 
───┴─────────

This is a list of integers, or two rows with an unnamed column

❯ echo "[{name: 1}, {name: 2}]" | from json
───┬──────
 # │ name 
───┼──────
 0 │    1 
 1 │    2 
───┴──────

This is a list of objects, or two rows with a name column.

wrap name can be used to turn the first form into the second form.

In the table output both looks almost identical, but when parsing or serializing (e.g. to/from json), both forms have their use.

created time in 2 months

delete branch jzaefferer/nushell

delete branch : 1709-from-docs

delete time in 2 months

PR opened nushell/nushell

docs/commands: add to.md, update subcommands

This adds a top-level document for the new to command, with a list (of links) of all the subcommands.

All the to-* subcommands keep their filename, but the content is updated to use the new subcommand syntax.

Since not all subcommands have documentation, some items in the list are just text without a link. Also filled the list for the undocumented from* commands in the same style.

Fixes #1709

+78 -22

0 comment

8 changed files

pr created time in 2 months

create barnchjzaefferer/nushell

branch : 1709-to-docs

created branch time in 2 months

issue openednushell/nushell

which command should handle aliases

Is your feature request related to a problem? Please describe.

This is unexpected:

❯ config --get startup
───┬────────────────────────────────────────
 # │ <value>
───┼────────────────────────────────────────
 0 │ alias myecho [msg] { echo Hello $msg }
 1 │ alias s [] { git status -sb }
───┴────────────────────────────────────────
nushell on 📙 1709-from-docs is 📦 v0.13.1 via 🦀 v1.43.0
❯ which s
─────────┬──────────────────────────
 arg     │ s
 path    │ nushell built-in command
 builtin │ Yes
─────────┴──────────────────────────

Describe the solution you'd like I think which needs special handling for aliases. Maybe like this?

─────────┬──────────────────────────
 arg     │ s
 path    │ nushell alias: [] { git status -sb }
 builtin │ No
─────────┴──────────────────────────

Describe alternatives you've considered n/a

Additional context n/a

created time in 2 months

issue commentnushell/nushell

Feature request: Support for git

@techthumb @lukesutton re-reading the discussion here so far, I can't tell what nu could actually do here. Putting the output of git status into a table doesn't seem particularly useful by itself. And that's completely different from what scmpuff does (adding numbers to the output, which can then be used in other commands).

I personally use an alias called s all the time, for git status -sb and a mostly two variations of git log:

  • lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
  • lp = log -p -M90%

But I don't really see how nu can add anything useful to that. Could either of you elaborate?

techthumb

comment created time in 2 months

issue commentnushell/nushell

from <format> commands (make <format> a subcommand of from)

I think this is actually fixed by #1708 - as suggested, not using parse.

parse is still missing docs, and the built-in help help parse doesn't explain enough.

thomasheartman

comment created time in 2 months

PR opened nushell/nushell

docs/commands: add from.md, update subcommands

This adds a top-level document for the new from command, with a list of links of all the subcommands.

All the from-* subcommands keep their filename, but the content is updated to use the new subcommand syntax.

Needs matching update for to*

Ref #1709

I figured I start with the one - once that's approved, I know what to do better for the other.

+111 -59

0 comment

11 changed files

pr created time in 2 months

create barnchjzaefferer/nushell

branch : 1709-from-docs

created branch time in 2 months

push eventjzaefferer/nushell

Joseph T. Lyons

commit sha ef3049f5a116276633645a9a2c9aa587bf3af429

Reduce some repetitive code in files.rs (#1692)

view details

chrisr

commit sha ada92f41b46a676750ab0ff2c8042d84f6017eed

Parse file size (byte) units in all mixes of case (#1693)

view details

Jörn Zaefferer

commit sha 0779a461794ebfec0690ef5652a67b86407b5571

docs/commands: add alias.md (#1697) * docs/commands: add alias.md * docs/commands/alias: drop reference to bash

view details

Joseph T. Lyons

commit sha 8d69c7798992e0f6a3ccddf9cc07542ea8d01414

Display either dir metadata size or dir apparent size in `ls` (#1696) * Show dir size in ls command * Add the option to show the apparent directory size via `ls --du`

view details

chrisr

commit sha d7d487de73ef5a2381a24666c2ce3b46e93b2658

Basic documentation for the wrap command (#1704)

view details

Joseph T. Lyons

commit sha 81ff598d6cbf476be8525d56833e3e660d8c1c98

Fix column bugs associated with previous refactoring (#1705) * Fix: the symlink target column will only dispaly if either the `full` or `with_symlink_targets` options are given * If the metadata for every item in the size column is None, do not show the size column * Do not show the symlink target column if the metadata is None for all the items in the table

view details

Jonathan Turner

commit sha 453087248ad8cf67f36757e116e913b350f5f3b2

Properly drain iterating pipe so we can see errors (#1707)

view details

Jonathan Turner

commit sha a9968046ede45827dfa1986f00059179e40b2c18

Add subcommands. Switch from-* and to-* to them (#1708)

view details

Darren Schroeder

commit sha d2ac506de3219fdc4825bb492f06e8cf5882887b

Changes to allow plugins to be loaded in a multi-threaded manner (#1694) * Changes to allow plugins to be loaded in a multi-threaded manner in order to decrease startup time. * Ran rust fmt and clippy to find and fix first pass errors. Updated launch.jason to make debugging easier in vscode. Also added tasks.json so tasks like clippy can be ran easily. * ran fmt again * Delete launch.json Remove IDE settings file * Remove IDE settings file * Ignore vscode IDE settings * Cloned the context instead of Arc/Mutexing it. Co-authored-by: Darren Schroeder <fdncred@hotmail.com> Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>

view details

push time in 2 months

PR opened nushell/nushell

Extend to/from usage text to indicate subcommands

Both to and from without a subcommand only print the helptext. Expand the usage line a bit, so a glance at help commands indicates the existance of the subcommands and mentions some common formats.

Ref a9968046ede45827dfa1986f00059179e40b2c18 Ref #1708

+2 -2

0 comment

2 changed files

pr created time in 2 months

create barnchjzaefferer/nushell

branch : to-form-usage-extended

created branch time in 2 months

issue commentnushell/nushell

More/better escaping for passing $it to native commands

I can confirm this, too, now that I've managed to build from master

jzaefferer

comment created time in 2 months

pull request commentnushell/book

coming from bash: touch equivalent is (now) possible

Updated, now showing bash touch being equivalent to nushell touch

jzaefferer

comment created time in 2 months

push eventjzaefferer/book

Jörn Zaefferer

commit sha 27951fbcc0cc9affed773e21d2533c0899a17bb0

coming from bash: touch was added Removing the `| save <filename.ext>` line since there's no match in bash (accordingly the Bash cell is empty). That's pointless in this context - `save` is documented elsewhere.

view details

push time in 2 months

PR opened nushell/book

configuration: remove superflous 'on'

Follow-up to #73 - I noticed this only after it was merged

+8 -8

0 comment

1 changed file

pr created time in 2 months

create barnchjzaefferer/book

branch : config-typo

created branch time in 2 months

pull request commentnushell/book

coming_from_bash: add alias in 4 variations

This is no longer a draft

jzaefferer

comment created time in 2 months

pull request commentnushell/book

coming from bash: touch equivalent is (now) possible

Now how do I use nu to compare the output of nushell/docs/commands to help commands to find the missing docs...?

jzaefferer

comment created time in 2 months

pull request commentnushell/book

coming from bash: touch equivalent is (now) possible

nushell/docs/commands has 69 files, while help commands has 111 rows. Are there really that many undocumented commands?

jzaefferer

comment created time in 2 months

pull request commentnushell/book

coming from bash: touch equivalent is (now) possible

Maybe maintainers could check PRs with new commands for a matching docs/commands/ addition?

Meanwhile I'll look into writing the docs for these missing commands...

jzaefferer

comment created time in 2 months

pull request commentnushell/book

coming from bash: touch equivalent is (now) possible

Once I realized that a lot of commands are missing on https://www.nushell.sh/documentation.html I remembered touch again - turns out that has been implemented a little while ago, but not documented: https://github.com/nushell/nushell/pull/1399

I'll update this accordingly.

jzaefferer

comment created time in 2 months

issue commentnushell/nushell

help commands also displays the type of command

https://www.nushell.sh/book/en/pipeline.html talks about input (instead of source), filter and output (instead of sink).

config is both input (--get) and output (--set), right?

Maybe cd, exit, shells could be of type shell or navigation?

Looks like cp and mv are missing docs (at least on https://www.nushell.sh/documentation.html ), maybe that's type filesystem?

kvrhdn

comment created time in 2 months

issue commentnushell/nushell

An easy way to give a name to an unnamed <value> column

Related to #903

Btw. I couldn't find any mention of <value> in the book, as if that doesn't exist at all.

Not even the docs for the get command has that anywhere: https://www.nushell.sh/commands/get.html Even though its really easy to produce a list with <value> using get, like ls | get name

nespera

comment created time in 2 months

issue openednushell/nushell

Command for opening files (and URLs) in their app

Is your feature request related to a problem? Please describe. To open files in their associated apps, different OSes have different native commands: open on OSX, start on Windows, xdg-open on Linux. A nushell command to enscapulate those different commands would fill a gap and avoid using external commands.

Describe the solution you'd like

A command like open (on OSX), but in nushell. Since the name open is already taken, something else is needed. Maybe start like on Windows.

Describe alternatives you've considered Alternative is to use the "local" native version (like ^open).

Additional context A rust crate that implements this: https://crates.io/crates/open this has fallbacks for other commands on linux, not only xdg-open

An apparently well maintained nodejs package for the equivalent function: https://github.com/sindresorhus/open interestingly/weirdly it ships with a copy of xdg-open

created time in 2 months

issue openednushell/nushell

More/better escaping for passing $it to native commands

Is your feature request related to a problem? Please describe.

My question was: How do I pass the output of a command to an external command, with proper escaping?

I want to use the code external command to edit nu's config file. This almost works:

config --path | code $it

Unfortunately that path contains a space (on OSX, "Application Support"), so it actually opens two non-existing files (~/Library/Application and Support/nu/config.toml)

Describe the solution you'd like

According to @jonathandturner on Discord, there's some automatic escaping in place, but he thinks it needs more.

Describe alternatives you've considered

config --path | code "$it" makes it worse (code expected a string)

Additional context

Another way to reproduce this:

> config --path | ^cat $it
cat: ~/Library/Application: No such file or directory
cat: Support/nu/config.toml: No such file or directory

The motivation to edit the nu/config.toml originally came from wanting to edit aliases there, instead of using rather complicated inline pipelines using config --get etc.

created time in 2 months

Pull request review commentnushell/book

Add CONTRIBUTING.md with local Docker setup

+# Contributing++If you want to contribute to nushell itself, see [nushell/nushell/CONTRIBUTING.md](https://github.com/nushell/nushell/blob/master/CONTRIBUTING.md) and the [contributor-book](https://github.com/nushell/contributor-book).++This book is based on Jekyll, which requires Ruby.++## Running locally with Docker

Thanks, added! I changed the port for the Docker version to use 4000, too. Though I kept "localhost:4000" for both versions. Or is there a specific reason to the use IP?

jzaefferer

comment created time in 2 months

push eventjzaefferer/book

Jörn Zaefferer

commit sha 8e4cd37275a7ffcb8df929a976540bf8d91c2300

contributing: add instructions for bundler Use port 4000 for both variants

view details

push time in 2 months

Pull request review commentnushell/nushell

docs/commands: add alias.md

+# alias+This command allows you to define shortcuts for common commands, equivalent to the same bash command.

I removed the bash reference. Added "other" in front of "common commands", since the sentence already starts with "This command".

jzaefferer

comment created time in 2 months

push eventjzaefferer/nushell

Jörn Zaefferer

commit sha 98082381030c65b2220256895a2722858803dba9

docs/commands/alias: drop reference to bash

view details

push time in 2 months

Pull request review commentnushell/nushell

docs/commands: add alias.md

+# alias+This command allows you to define shortcuts for common commands, equivalent to the same bash command.++The command expects three parameters:+* the name of alias+* the parameters as a space-separated list (`[a b ...]`), can be empty (`[]`)+* the body of the alias as a `{...}` block++## Examples++Define a custom `myecho` command as an alias:+```shell+> alias myecho [msg] { echo $msg }+> myecho "hello world"+hello world+```++Since the parameters are well defined, calling the command with the wrong number of parameters will fail properly:+```shell+> myecho hello world+error: myecho unexpected world+- shell:1:18+1 | myecho hello world+  |              ^^^^^ unexpected argument (try myecho -h)+```++The suggested help command works!+```shell+> myecho -h++Usage:+  > myecho ($msg) {flags}++parameters:+  ($msg)++flags:+  -h, --help: Display this help message+```++## Persistent aliases++Aliases are most useful when they are persistent. For that, add them to your startup config:+```+> config --set [startup ["alias myecho [msg] { echo $msg }"]]+```+This is fine for the first alias, but since it overwrites the startup config, you need a different approach for additional aliases.++To add a 2nd alias:+```+config --get startup | append "alias s [] { git status -sb }" | config --set_into startup+```+This first reads the `startup` config (a table of strings), then appends another alias, then sets the `startup` config with the output of the pipeline.++To make this process easier, you could define another alias:+```+> alias addalias [alias-string] { config --get startup | append $alias-string | config --set_into startup }

As I wrote in my PR description: "Arguably this shows the need for better managing of alias commands." 😉

jzaefferer

comment created time in 2 months

Pull request review commentnushell/nushell

docs/commands: add alias.md

+# alias+This command allows you to define shortcuts for common commands, equivalent to the same bash command.++The command expects three parameters:+* the name of alias+* the parameters as a space-separated list (`[a b ...]`), can be empty (`[]`)

I added it after trying [a, b] first. I think in this case a little bit of redundancy is good.

If you think it really doesn't belong here, I suggest adding an example with multiple parameters instead. Though I'd need some idea for that, since all my bash alias take no arguments or forward them to the underlying command instead (d --staged => git diff --staged).

jzaefferer

comment created time in 2 months

PR opened nushell/nushell

docs/commands: add alias.md

Arguably this shows the need for better managing of alias commands.

Or tell people to edit the nu/config.toml directly. I didn't include that here since I had some trouble passing config --path to my editor: https://discordapp.com/channels/601130461678272522/614593951969574961/706131398783926284

+62 -0

0 comment

1 changed file

pr created time in 2 months

push eventjzaefferer/nushell

Jörn Zaefferer

commit sha e38ce5a694c6d77dbf7583d180250db63fb0ad2a

docs/commands: add alias.md

view details

push time in 2 months

create barnchjzaefferer/nushell

branch : docs-add-alias-command

created branch time in 2 months

push eventjzaefferer/book

Jörn Zaefferer

commit sha df6dc1b30fd9bcef057d47da29063d0fd5ece9db

coming_from_bash: add/edit alias in 4 variations

view details

push time in 2 months

push eventjzaefferer/book

Jörn Zaefferer

commit sha 16afc55868b718122828efd27218986707e2234a

coming_from_bash: add/edit alias in 4 variations

view details

push time in 2 months

push eventjzaefferer/book

Jörn Zaefferer

commit sha 145c5f026704f7bd5154c6efef5eb673d91e2cb0

coming_from_bash: add alias in 3 variations

view details

push time in 2 months

PR opened nushell/book

configuration: add startup variable

I'm guessing the type and description based on the 0.13.0 release blog post: https://www.nushell.sh/blog/2020/04/21/nushell_0_13_0.html#startup-commands-jonathandturner

I still haven't figured out what "table of strings" actually is. The types documentation doesn't mention them: https://www.nushell.sh/book/en/types_of_data.html

This has a good chance to be correct anyway, even if not particularly helpful without an example - see #72 for my struggle with examples for startup.

+1 -0

0 comment

1 changed file

pr created time in 2 months

create barnchjzaefferer/book

branch : configuration-startup

created branch time in 2 months

PR opened nushell/book

coming_from_bash: add alias in 3 variations

The third example is broken and I haven't yet figured out how to make it work. I can't yet tell what format startup has, and its itself missing from the docs ( https://www.nushell.sh/book/en/configuration.html ).

+3 -0

0 comment

1 changed file

pr created time in 2 months

more