## Attendees
- storm
- fdncred
- sholderbach
- amtoine
- kubouch
- jt
- andres

## Agenda
- [x] (*quick topic*) CI does not behave as expected: @amtoine might need help :scream: ([amtoine/nushell#5](https://github.com/amtoine/nushell/pull/5))
- clarify offline -> Stefan, Antoine
- [x] (*quick topic*) aliasing `type` to `which` to avoid confusion ([#5196](https://github.com/nushell/nushell/issues/5196#issuecomment-1616961170)) => change the coloring
- [x] Breaking changes policy
- Balancing act but also clear communication to our users
- True deprecation for graceful migration?
- User complaint: https://discord.com/channels/601130461678272522/988303282931912704/1124693615470452936
- We don't exist in a vacuum anymore as we have integrations with other tools that have their own release schedules and may not always be available to users in compatible versions.
- We need to be bold to reach 1.0 (inspirational example [Andrew Kelley's push for llvmectomy in zig](https://github.com/ziglang/zig/issues/16270#issuecomment-1616115039))
- [x] What other breaking changes should we aim for in the near term?
- [x] `$in`
- Any changes to its behavior?
- New name?
- Poll: https://discord.com/channels/601130461678272522/615329862395101194/1125170250690875454
- Issue: https://github.com/nushell/nushell/issues/9551
- Make it a warning/error/lint if you use it like `{ $in | command }`?
- https://github.com/nushell/nushell/issues/9551#issuecomment-1617058335
- [ ] New issue labels
- `release-note-mention` to highlight PRs that should be reflected in the release notes even if they are not breaking changes
- `new-command` to raise awareness for PRs introducing new commands
- TODO: strengthening and also consolidating our list of labels
- [ ] Non-English issues on GH
- Problem: don't contribute to the general discussion and need to be serendipidously picked up by native speaker (translatable but not searchable).
- Outright closing them might be a bit harsh
- Maybe only allow non-English only in "Discussions" with a language prefix or when helping out one-on-one via code-review comment threads.

# Discussed Topics

## Confusion on BSD with `type` command and relationship to nu's `which`
- cross-platform issue: BSD preference colliding with `type` on Win
- clarify with commenter
- can this be resolved by personal settings
- better highlighting for internals vs externals necessary in our theme?

## Breaking changes policy

- Darren: Deprecation vs Removal, we just remove and provide some help
- JT: delay until it is finally removed, it would be great to also add metadata to commands (e.g. deprecated for custom commands, desire for metadata already came up with testing)
- let's get the correct style of deprecation soon
- institute stricter deprecation policy e.g. around 0.90
- no yeeting commands without soft warning

## Detour: Docs are in a state of a few months ago
- commands are suggested that are already deprecated/removed
- Q JT: how do we want to teach nushell in the future
- Tutorial style to introduce to get productive
- Darren: cookbook is a great way to learn for me. can we get some great real world examples
- JT: make the cookbook more visible or interleaved in one book
- Jakub: have a story line of an example project going through the learning book (see The Book from Rust) maybe also a good candidate for the `tutor` command
- Amtoine: are we ready to invest the time with the state of the project
- JT: the gist of nushell is pretty settled, Pipelines
- As technical writing goal: [Nu Language Guide](/hLTipwOaR2K28GzwHrtVGQ) may also serve as a specification and reference for developers
- CI testing of the docs code samples!
- should be doable
- we already have some code in snippet files
- How with triple backtick sections? is there a way to hook into VuePress?
## Planned breaking changes:
### Storm: moving `math` commands
- Stefan: let's give it a go and if it hurts let's move highly requested ones back
- Plugins could also become an option for mitigation
## Syntax to express (table types
### JT's suggestion of having look-a-like type syntax
`x: [int]` # list of ints
`x: {y: int}` # record of one field
`x: [{y: int}]` # table of one column
### current proposal based on 1kinoti's PRs

x: list<int>
x: record<y: int>
x: table<y: int>

- Table PR: https://github.com/nushell/nushell/pull/9613
- Jakub: not very surprising for types
- JT: maybe the types should be capitalized

    x: List<int>
    x: Record<y: int>
    x: Table<y: int>

- containers capital, primitive types lowercase?
- would be following Java/Rust and a lot of languages
- follows the good ol' `describe`
### Not liked:

list(int)

### Conclusion for this meeting
**General preference for the more explicit style `Table<...>`**
(benefit of the "nominal" type for containers that we could hide the implementation details or specialize in the future if we want a columnar table type or different maps instead of record)
## Lightning round: `$in`
- issue: its non streaming behavior is not quite obvious
- Jakub: we got pretty used to it
- Maybe warning/linting if you use it at the first pipeline element of a block/closure

    # this is ok

    def len [] {
      str length
    }

    # this is not ok? based on performance/streaming properties
    # but more explicit
    def len [] {
      $in | str length
    }

- JT: it makes things obvious in some places:

  if ($in | str length) { ... }
  if (str length) { ... }

- Automagical optimization?
- eliding it in the leading pipeline position internally before evaluating?
- is it too surprising?
- JT: `let x = $in` is the same as `let x = ($in)`
## Issues
> :bulb: the issues which [needs-core-team-attention](https://github.com/nushell/nushell/labels/needs-core-team-attention)

> :bulb: **Note**
> to list all the PRs currently [opened in `nushell/nushell`](https://github.com/nushell/nushell/pulls):
> ```nu
> gh pr list --json url,number,author,title
> | from json
> | each {|i|
> $"- [($i.number)]\(($i.url)\) ($i.title) \(@($i.author.login)\)"
> }
> | reverse
> | to text
> ```