Point to super/issues instead of zed/issues

versioned_docs/version-v1.10.0/integrations/amazon-s3.md

@@ -44,5 +44,5 @@ environment variable to the hostname or URI of the provider.
 [Like the AWS CLI tools themselves](https://repost.aws/knowledge-center/s3-event-notification-filter-wildcard),
 Zed does not currently expand UNIX-style `*` wildcards in S3 URIs. If you
 find this limitation is impacting your workflow, please add your use case
-details as a comment in issue [zed/1994](https://github.com/brimdata/zed/issues/1994)
+details as a comment in issue [zed/1994](https://github.com/brimdata/super/issues/1994)
 to help us track the priority of possible enhancements in this area.

versioned_docs/version-v1.10.0/integrations/zeek/shaping-zeek-ndjson.md

@@ -308,8 +308,8 @@ steps:
       ... | put this := shape(schemas[_path]) | put this := crop(schemas[_path])
       ```
 
-   Open issues [zed/2585](https://github.com/brimdata/zed/issues/2585) and
-   [zed/2776](https://github.com/brimdata/zed/issues/2776) both track planned
+   Open issues [zed/2585](https://github.com/brimdata/super/issues/2585) and
+   [zed/2776](https://github.com/brimdata/super/issues/2776) both track planned
    future improvements to this part of Zed shapers.
 
 ## Invoking the Shaper From `zq`
@@ -383,13 +383,13 @@ originating IP address:
 zq -I shaper.zed -f table '| count() by network_of(id.orig_h) | sort -r' conn.log
 ```
 
-[zed/2584](https://github.com/brimdata/zed/issues/2584) tracks a planned
+[zed/2584](https://github.com/brimdata/super/issues/2584) tracks a planned
 improvement for this use of `zq -I`.
 
 If you intend to frequently shape the same NDJSON data, you may want to create
 an alias in your
 shell to always invoke `zq` with the necessary `-I` flag pointing to the path
-of your finalized shaper. [zed/1059](https://github.com/brimdata/zed/issues/1059)
+of your finalized shaper. [zed/1059](https://github.com/brimdata/super/issues/1059)
 tracks a planned enhancement to persist such settings within Zed itself rather
 than relying on external mechanisms such as shell aliases.
 
@@ -398,7 +398,7 @@ than relying on external mechanisms such as shell aliases.
 If you wish to browse your shaped data with [Zui](https://zui.brimdata.io/),
 the best way to accomplish this at the moment would be to use `zq` to convert
 it to ZNG [as shown above](#invoking-the-shaper-from-zq), then drag the ZNG
-into Zui as you would any other log. An enhancement [zed/2695](https://github.com/brimdata/zed/issues/2695)
+into Zui as you would any other log. An enhancement [zed/2695](https://github.com/brimdata/super/issues/2695)
 is planned that will soon make it possible to attach your shaper to a
 Pool. This will allow you to drag the original NDJSON logs directly into the
 Pool in Zui and have the shaping applied as the records are being committed to
@@ -408,5 +408,5 @@ the Pool.
 
 If you're having difficulty, interested in shaping other data sources, or
 just have feedback, please join our [public Slack](https://www.brimdata.io/join-slack/)
-and speak up or [open an issue](https://github.com/brimdata/zed/issues/new/choose).
+and speak up or [open an issue](https://github.com/brimdata/super/issues/new/choose).
 Thanks!

versioned_docs/version-v1.10.0/language/statements.md

@@ -207,9 +207,9 @@ allowed and will produce an error.
 
 User-defined operators are a new feature in Zed that has been made available
 despite known limitations described in open issues
-[zed/4651](https://github.com/brimdata/zed/issues/4651),
-[zed/4692](https://github.com/brimdata/zed/issues/4692), and
-[zed/4701](https://github.com/brimdata/zed/issues/4701). If you encounter
+[zed/4651](https://github.com/brimdata/super/issues/4651),
+[zed/4692](https://github.com/brimdata/super/issues/4692), and
+[zed/4701](https://github.com/brimdata/super/issues/4701). If you encounter
 these or other problems when making use of the feature please comment on the
 issues or come talk to us on the [Brim community Slack](https://www.brimdata.io/join-slack/)
 as this will help guide the priority with which these limitations are

versioned_docs/version-v1.10.0/language/ztests/language-directed-acyclic-flow-graphs-1.yaml

@@ -17,7 +17,7 @@
 # Specifically, the "op1", "op2", and "..." have been filled in with real
 # operations, and the "merge" has been replaced with a "sort" for now since
 # merge has not yet been fully implemented
-# (https://github.com/brimdata/zed/issues/2906).
+# (https://github.com/brimdata/super/issues/2906).
 
 script: |
   export ZED_LAKE=test

versioned_docs/version-v1.10.0/language/ztests/language-directed-acyclic-flow-graphs-2.yaml

@@ -16,7 +16,7 @@
 #
 # Specifically, the "op1", "op2", and "..." have been filled in with real
 # operations, and a field assignment has been added to the join
-# (https://github.com/brimdata/zed/issues/2815).
+# (https://github.com/brimdata/super/issues/2815).
 
 script: |
   export ZED_LAKE=test

versioned_docs/version-v1.10.0/tutorials/join.md

@@ -333,7 +333,7 @@ produces
 
 In the current `join` implementation, explicit entries must be provided in the
 `[field-list]` in order to copy values from the opposite input into the joined
-results (a possible future enhancement [zed/2815](https://github.com/brimdata/zed/issues/2815)
+results (a possible future enhancement [zed/2815](https://github.com/brimdata/super/issues/2815)
 may improve upon this). This can be cumbersome if your goal is to copy over many
 fields or you don't know the names of all desired fields.
 

versioned_docs/version-v1.11.0/integrations/amazon-s3.md

@@ -44,5 +44,5 @@ environment variable to the hostname or URI of the provider.
 [Like the AWS CLI tools themselves](https://repost.aws/knowledge-center/s3-event-notification-filter-wildcard),
 Zed does not currently expand UNIX-style `*` wildcards in S3 URIs. If you
 find this limitation is impacting your workflow, please add your use case
-details as a comment in issue [zed/1994](https://github.com/brimdata/zed/issues/1994)
+details as a comment in issue [zed/1994](https://github.com/brimdata/super/issues/1994)
 to help us track the priority of possible enhancements in this area.

versioned_docs/version-v1.11.0/integrations/zeek/shaping-zeek-ndjson.md

@@ -308,8 +308,8 @@ steps:
       ... | put this := shape(schemas[_path]) | put this := crop(schemas[_path])
       ```
 
-   Open issues [zed/2585](https://github.com/brimdata/zed/issues/2585) and
-   [zed/2776](https://github.com/brimdata/zed/issues/2776) both track planned
+   Open issues [zed/2585](https://github.com/brimdata/super/issues/2585) and
+   [zed/2776](https://github.com/brimdata/super/issues/2776) both track planned
    future improvements to this part of Zed shapers.
 
 ## Invoking the Shaper From `zq`
@@ -383,13 +383,13 @@ originating IP address:
 zq -I shaper.zed -f table '| count() by network_of(id.orig_h) | sort -r' conn.log
 ```
 
-[zed/2584](https://github.com/brimdata/zed/issues/2584) tracks a planned
+[zed/2584](https://github.com/brimdata/super/issues/2584) tracks a planned
 improvement for this use of `zq -I`.
 
 If you intend to frequently shape the same NDJSON data, you may want to create
 an alias in your
 shell to always invoke `zq` with the necessary `-I` flag pointing to the path
-of your finalized shaper. [zed/1059](https://github.com/brimdata/zed/issues/1059)
+of your finalized shaper. [zed/1059](https://github.com/brimdata/super/issues/1059)
 tracks a planned enhancement to persist such settings within Zed itself rather
 than relying on external mechanisms such as shell aliases.
 
@@ -398,7 +398,7 @@ than relying on external mechanisms such as shell aliases.
 If you wish to browse your shaped data with [Zui](https://zui.brimdata.io/),
 the best way to accomplish this at the moment would be to use `zq` to convert
 it to ZNG [as shown above](#invoking-the-shaper-from-zq), then drag the ZNG
-into Zui as you would any other log. An enhancement [zed/2695](https://github.com/brimdata/zed/issues/2695)
+into Zui as you would any other log. An enhancement [zed/2695](https://github.com/brimdata/super/issues/2695)
 is planned that will soon make it possible to attach your shaper to a
 Pool. This will allow you to drag the original NDJSON logs directly into the
 Pool in Zui and have the shaping applied as the records are being committed to
@@ -408,5 +408,5 @@ the Pool.
 
 If you're having difficulty, interested in shaping other data sources, or
 just have feedback, please join our [public Slack](https://www.brimdata.io/join-slack/)
-and speak up or [open an issue](https://github.com/brimdata/zed/issues/new/choose).
+and speak up or [open an issue](https://github.com/brimdata/super/issues/new/choose).
 Thanks!

versioned_docs/version-v1.11.0/language/ztests/language-directed-acyclic-flow-graphs-1.yaml

@@ -17,7 +17,7 @@
 # Specifically, the "op1", "op2", and "..." have been filled in with real
 # operations, and the "merge" has been replaced with a "sort" for now since
 # merge has not yet been fully implemented
-# (https://github.com/brimdata/zed/issues/2906).
+# (https://github.com/brimdata/super/issues/2906).
 
 script: |
   export ZED_LAKE=test

versioned_docs/version-v1.11.0/language/ztests/language-directed-acyclic-flow-graphs-2.yaml

@@ -16,7 +16,7 @@
 #
 # Specifically, the "op1", "op2", and "..." have been filled in with real
 # operations, and a field assignment has been added to the join
-# (https://github.com/brimdata/zed/issues/2815).
+# (https://github.com/brimdata/super/issues/2815).
 
 script: |
   export ZED_LAKE=test

versioned_docs/version-v1.11.0/tutorials/join.md

@@ -333,7 +333,7 @@ produces
 
 In the current `join` implementation, explicit entries must be provided in the
 `[field-list]` in order to copy values from the opposite input into the joined
-results (a possible future enhancement [zed/2815](https://github.com/brimdata/zed/issues/2815)
+results (a possible future enhancement [zed/2815](https://github.com/brimdata/super/issues/2815)
 may improve upon this). This can be cumbersome if your goal is to copy over many
 fields or you don't know the names of all desired fields.
 

versioned_docs/version-v1.12.0/integrations/amazon-s3.md

@@ -44,5 +44,5 @@ environment variable to the hostname or URI of the provider.
 [Like the AWS CLI tools themselves](https://repost.aws/knowledge-center/s3-event-notification-filter-wildcard),
 Zed does not currently expand UNIX-style `*` wildcards in S3 URIs. If you
 find this limitation is impacting your workflow, please add your use case
-details as a comment in issue [zed/1994](https://github.com/brimdata/zed/issues/1994)
+details as a comment in issue [zed/1994](https://github.com/brimdata/super/issues/1994)
 to help us track the priority of possible enhancements in this area.

versioned_docs/version-v1.12.0/integrations/zeek/shaping-zeek-ndjson.md

@@ -308,8 +308,8 @@ steps:
       ... | put this := shape(schemas[_path]) | put this := crop(schemas[_path])
       ```
 
-   Open issues [zed/2585](https://github.com/brimdata/zed/issues/2585) and
-   [zed/2776](https://github.com/brimdata/zed/issues/2776) both track planned
+   Open issues [zed/2585](https://github.com/brimdata/super/issues/2585) and
+   [zed/2776](https://github.com/brimdata/super/issues/2776) both track planned
    future improvements to this part of Zed shapers.
 
 ## Invoking the Shaper From `zq`
@@ -383,13 +383,13 @@ originating IP address:
 zq -I shaper.zed -f table '| count() by network_of(id.orig_h) | sort -r' conn.log
 ```
 
-[zed/2584](https://github.com/brimdata/zed/issues/2584) tracks a planned
+[zed/2584](https://github.com/brimdata/super/issues/2584) tracks a planned
 improvement for this use of `zq -I`.
 
 If you intend to frequently shape the same NDJSON data, you may want to create
 an alias in your
 shell to always invoke `zq` with the necessary `-I` flag pointing to the path
-of your finalized shaper. [zed/1059](https://github.com/brimdata/zed/issues/1059)
+of your finalized shaper. [zed/1059](https://github.com/brimdata/super/issues/1059)
 tracks a planned enhancement to persist such settings within Zed itself rather
 than relying on external mechanisms such as shell aliases.
 
@@ -398,7 +398,7 @@ than relying on external mechanisms such as shell aliases.
 If you wish to browse your shaped data with [Zui](https://zui.brimdata.io/),
 the best way to accomplish this at the moment would be to use `zq` to convert
 it to ZNG [as shown above](#invoking-the-shaper-from-zq), then drag the ZNG
-into Zui as you would any other log. An enhancement [zed/2695](https://github.com/brimdata/zed/issues/2695)
+into Zui as you would any other log. An enhancement [zed/2695](https://github.com/brimdata/super/issues/2695)
 is planned that will soon make it possible to attach your shaper to a
 Pool. This will allow you to drag the original NDJSON logs directly into the
 Pool in Zui and have the shaping applied as the records are being committed to
@@ -408,5 +408,5 @@ the Pool.
 
 If you're having difficulty, interested in shaping other data sources, or
 just have feedback, please join our [public Slack](https://www.brimdata.io/join-slack/)
-and speak up or [open an issue](https://github.com/brimdata/zed/issues/new/choose).
+and speak up or [open an issue](https://github.com/brimdata/super/issues/new/choose).
 Thanks!

versioned_docs/version-v1.12.0/language/ztests/language-directed-acyclic-flow-graphs-1.yaml

@@ -17,7 +17,7 @@
 # Specifically, the "op1", "op2", and "..." have been filled in with real
 # operations, and the "merge" has been replaced with a "sort" for now since
 # merge has not yet been fully implemented
-# (https://github.com/brimdata/zed/issues/2906).
+# (https://github.com/brimdata/super/issues/2906).
 
 script: |
   export ZED_LAKE=test

versioned_docs/version-v1.12.0/language/ztests/language-directed-acyclic-flow-graphs-2.yaml

@@ -16,7 +16,7 @@
 #
 # Specifically, the "op1", "op2", and "..." have been filled in with real
 # operations, and a field assignment has been added to the join
-# (https://github.com/brimdata/zed/issues/2815).
+# (https://github.com/brimdata/super/issues/2815).
 
 script: |
   export ZED_LAKE=test

versioned_docs/version-v1.12.0/tutorials/join.md

@@ -333,7 +333,7 @@ produces
 
 In the current `join` implementation, explicit entries must be provided in the
 `[field-list]` in order to copy values from the opposite input into the joined
-results (a possible future enhancement [zed/2815](https://github.com/brimdata/zed/issues/2815)
+results (a possible future enhancement [zed/2815](https://github.com/brimdata/super/issues/2815)
 may improve upon this). This can be cumbersome if your goal is to copy over many
 fields or you don't know the names of all desired fields.
 

versioned_docs/version-v1.13.0/integrations/amazon-s3.md

@@ -44,5 +44,5 @@ environment variable to the hostname or URI of the provider.
 [Like the AWS CLI tools themselves](https://repost.aws/knowledge-center/s3-event-notification-filter-wildcard),
 Zed does not currently expand UNIX-style `*` wildcards in S3 URIs. If you
 find this limitation is impacting your workflow, please add your use case
-details as a comment in issue [zed/1994](https://github.com/brimdata/zed/issues/1994)
+details as a comment in issue [zed/1994](https://github.com/brimdata/super/issues/1994)
 to help us track the priority of possible enhancements in this area.

versioned_docs/version-v1.13.0/integrations/zeek/shaping-zeek-ndjson.md

@@ -308,8 +308,8 @@ steps:
       ... | put this := shape(schemas[_path]) | put this := crop(schemas[_path])
       ```
 
-   Open issues [zed/2585](https://github.com/brimdata/zed/issues/2585) and
-   [zed/2776](https://github.com/brimdata/zed/issues/2776) both track planned
+   Open issues [zed/2585](https://github.com/brimdata/super/issues/2585) and
+   [zed/2776](https://github.com/brimdata/super/issues/2776) both track planned
    future improvements to this part of Zed shapers.
 
 ## Invoking the Shaper From `zq`
@@ -383,13 +383,13 @@ originating IP address:
 zq -I shaper.zed -f table '| count() by network_of(id.orig_h) | sort -r' conn.log
 ```
 
-[zed/2584](https://github.com/brimdata/zed/issues/2584) tracks a planned
+[zed/2584](https://github.com/brimdata/super/issues/2584) tracks a planned
 improvement for this use of `zq -I`.
 
 If you intend to frequently shape the same NDJSON data, you may want to create
 an alias in your
 shell to always invoke `zq` with the necessary `-I` flag pointing to the path
-of your finalized shaper. [zed/1059](https://github.com/brimdata/zed/issues/1059)
+of your finalized shaper. [zed/1059](https://github.com/brimdata/super/issues/1059)
 tracks a planned enhancement to persist such settings within Zed itself rather
 than relying on external mechanisms such as shell aliases.
 
@@ -398,7 +398,7 @@ than relying on external mechanisms such as shell aliases.
 If you wish to browse your shaped data with [Zui](https://zui.brimdata.io/),
 the best way to accomplish this at the moment would be to use `zq` to convert
 it to ZNG [as shown above](#invoking-the-shaper-from-zq), then drag the ZNG
-into Zui as you would any other log. An enhancement [zed/2695](https://github.com/brimdata/zed/issues/2695)
+into Zui as you would any other log. An enhancement [zed/2695](https://github.com/brimdata/super/issues/2695)
 is planned that will soon make it possible to attach your shaper to a
 Pool. This will allow you to drag the original NDJSON logs directly into the
 Pool in Zui and have the shaping applied as the records are being committed to
@@ -408,5 +408,5 @@ the Pool.
 
 If you're having difficulty, interested in shaping other data sources, or
 just have feedback, please join our [public Slack](https://www.brimdata.io/join-slack/)
-and speak up or [open an issue](https://github.com/brimdata/zed/issues/new/choose).
+and speak up or [open an issue](https://github.com/brimdata/super/issues/new/choose).
 Thanks!

versioned_docs/version-v1.13.0/language/ztests/language-directed-acyclic-flow-graphs-1.yaml

@@ -17,7 +17,7 @@
 # Specifically, the "op1", "op2", and "..." have been filled in with real
 # operations, and the "merge" has been replaced with a "sort" for now since
 # merge has not yet been fully implemented
-# (https://github.com/brimdata/zed/issues/2906).
+# (https://github.com/brimdata/super/issues/2906).
 
 script: |
   export ZED_LAKE=test

versioned_docs/version-v1.13.0/language/ztests/language-directed-acyclic-flow-graphs-2.yaml

@@ -16,7 +16,7 @@
 #
 # Specifically, the "op1", "op2", and "..." have been filled in with real
 # operations, and a field assignment has been added to the join
-# (https://github.com/brimdata/zed/issues/2815).
+# (https://github.com/brimdata/super/issues/2815).
 
 script: |
   export ZED_LAKE=test

versioned_docs/version-v1.13.0/tutorials/join.md

@@ -333,7 +333,7 @@ produces
 
 In the current `join` implementation, explicit entries must be provided in the
 `[field-list]` in order to copy values from the opposite input into the joined
-results (a possible future enhancement [zed/2815](https://github.com/brimdata/zed/issues/2815)
+results (a possible future enhancement [zed/2815](https://github.com/brimdata/super/issues/2815)
 may improve upon this). This can be cumbersome if your goal is to copy over many
 fields or you don't know the names of all desired fields.
 

versioned_docs/version-v1.14.0/integrations/amazon-s3.md

@@ -44,5 +44,5 @@ environment variable to the hostname or URI of the provider.
 [Like the AWS CLI tools themselves](https://repost.aws/knowledge-center/s3-event-notification-filter-wildcard),
 Zed does not currently expand UNIX-style `*` wildcards in S3 URIs. If you
 find this limitation is impacting your workflow, please add your use case
-details as a comment in issue [zed/1994](https://github.com/brimdata/zed/issues/1994)
+details as a comment in issue [zed/1994](https://github.com/brimdata/super/issues/1994)
 to help us track the priority of possible enhancements in this area.