Extra propagation-keys are (also) removed from messages, and henceforth unavailable

Hi! Using Finchley.SR1 I'd like to take advantage of spring.sleuth.propagation-keys to propagate a few internal headers with my Kafka mesages, which we currently do manually. However, when I add the property to our configuration, the extra headers are stripped before they reach my @KafkaListener, which then raises a MessageHandlingException: Missing header 'corporate_trace_id' for method parameter type [class java.lang.String].
This commit introduces the problem to a demo project of mine:
https://github.com/timtebeek/sleuth-kafkalistener/commit/eb68995605abdb1d9051b15cc5415e80f6b37cc4#diff-9588a0ac6aee0ef700ab1dc6a13d0e04R71
I'm not sure if this is a Brave or Sleuth issue; reading ExtraFieldPropagation.get it seems I should be able to extract the value that way. Should I update my code to do that? Or is this something that should work out of the box? I was surprised to see a sleuth property break my listener, hence the question here.

@timtebeek have you checked this on 2 separate applications? Sometimes the tests might be misleading (I'm not saying that sth is not wrong here)

Yes it's in two projects, one at work, and the replication project linked
above. It's actually caused by this line:
https://github.com/openzipkin/brave/blob/release-5.2.0/instrumentation/kafka-clients/src/main/java/brave/kafka/clients/TracingConsumer.java#L89
But looking at the current master branch for brave that has since been
changed/moved. I realized after I posted here it's in brave instead, sorry
about that.
On Fri, Sep 7, 2018, 16:51 Marcin Grzejszczak<EMAIL_ADDRESS>wrote:

@timtebeek https://github.com/timtebeek have you checked this on 2
separate applications? Sometimes the tests might be misleading (I'm not
saying that sth is not wrong here)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/spring-cloud/spring-cloud-sleuth/issues/1083#issuecomment-419464175,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-tBsL_TOzR5daLXee5QF73GSxwgYUyks5uYofZgaJpZM4WWn6U
.

No problem. I'll close this one then.


I am trying to use react-native-google-signin with react-native-onesignal

Both this repo working correctly alone.
But when I am adding:
    compile fileTree(dir: "libs", include: ["*.jar"])
    compile "com.android.support:appcompat-v7:23.0.1"
    compile "com.facebook.react:react-native:+"
    compile(project(":react-native-google-signin")){
        exclude group: "com.google.android.gms" // very important
    }
    compile 'com.google.android.gms:play-services-auth:9.2.1'
}

apply plugin: 'com.google.gms.google-services'

inside android/app/build.grade I am getting following error
:app:processDebugGoogleServices FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:processDebugGoogleServices'.
> No matching client found for package name 'com.pushnotification'

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 13.856 secs
Could not install the app on the device, read the error above for details.
Make sure you have an Android emulator running or a device connected and have
set up your Android development environment:
https://facebook.github.io/react-native/docs/android-setup.html

@rahul3103 since this is an old issue and has had no activity we gonna close this, if this is a still a problem for you please re-open it and add a snippet of your build.gradle file. this is clearly a problem with dependency handling with Android and not with this library.

Same issue here

I changed the app_id of the onesignal in the app to a new one and it worked.


Loop fix

I moved the index of the previous find call to a new attribute (pos) and created a method to manually set it, also it gets rest to 0 on every new axs.
This should hopefully fix the issue where the finds method can't be reset, say if you want to create a display that periodically checks an RSS and scrolls it.

I wanted to use this library to periodically check on an RSS source and always get the second item, whether it had changed or stayed the same. Unfortunately, in the original library I could not reset the indexes for the "finds" method, so it would never go back to the beginning of the feed. This patch does the trick for me, and may be useful to someone else.


Harden deploy workflows against bad releases

Related Issue or Background Info
We discovered during last week's amazing run of awesome things that it was possible to have something work its way through our ZDD release process without ever actually having a valid health check. This PR addresses several issues related to that problem.
Changes Proposed

added readiness check to the application actuator, so that we can test explicitly for all commandlinerunner and initialization code having run
added configurable timeout for curl calls used in deployment jobs to reduce (although sadly not eliminate) the risk of getting a positive result after waiting for 30 seconds for the one successful response that the instance will ever give
added check- and wait-for- wildcard targets to check either the main instance or the staging/prerelease slot for

the correct commit being deployed
the correct release being deployed (obviously only to be used in release-driven environments)
the application returning a non-error response on its readiness-check endpoint

added checks for the application being "ready" before and after promoting from the deployment slot
removed the ability to deploy stg manually
made stg and prod check for the release rather than the commit hash, to make sure that reverts aren't weird

Additional Information

this does not include the changes for #1634 because they are quite small in comparison and can be in a separate PR with less noise

Checklist for Author and Reviewer
Reviewers should probably mostly look at just one deploy (say, deployDev.yml, since the changes are the same in all the non-prod deploys (stg and prod have one change that the others do not, since they are now release-driven rather than commit-driven).
Testing

[x] Includes a summary of what a code reviewer should verify

Cloud

[x] DevOps team has been notified if PR requires ops support
[x] If there are changes that cannot be tested locally, this has been deployed to our Azure test environment for verification

Feedback is addressed (I think it was just the timeouts?)

Yep! Approved.


Example Vega.lite bar chart does not render in IRuby Jupyter notebook

iruby 0.7.4
ruby 3.0.4
vega-ruby 0.2.6
jupyter lab 3.3.2
Notebook command:
Vega.lite
  .data([{city: "A", sales: 28}, {city: "B", sales: 55}, {city: "C", sales: 43}])
  .mark(type: "bar", tooltip: true)
  .encoding(
    x: {field: "city", type: "nominal"},
    y: {field: "sales", type: "quantitative"}
  )

vega-ruby creates html code

html code is not rendered in jupyter lab

This might be an issue of jupyterlab? Daruview with googlecharts renders fine.

Hey @dorra, thanks for reporting. It looks like RequireJS isn't included in JupyterLab, which is causing an error. Not sure when I'll be able to put together a fix, but it should work in Jupyter Notebook in the meantime.

Hi @ankane - thank you for the swift reply. Yes, it seems to work in every other client or environment than jupyter lab.
That's a real shame, we are in the process of building a data analysis environment. A server oriented environment is useful ;)
Thanks for your great open source contributions!

@ankane here is an interim solution:
require 'net/http'
require 'vega'
IRuby.html "<script>#{Net::HTTP.get(URI('https://requirejs.org/docs/release/2.3.6/minified/require.js'))}</script>"

Vega.lite
  .data([{city: "A", sales: 28}, {city: "B", sales: 55}, {city: "C", sales: 43}])
  .mark(type: "bar", tooltip: true)
  .encoding(
    x: {field: "city", type: "nominal"},
    y: {field: "sales", type: "quantitative"}
  )

Quick update: it looks like Jupyter Lab has built-in support for Vega/Vega-Lite, but haven't had any luck getting it working with Ruby.


Automate GPU Inventory Collection

https://github.com/openbmc/openbmc/issues/1044 - GPU Inventory Collection

I see GPU inventory has already been implemented.     For example,
curl -c cjar -b cjar -k https://$BMC_IP/xyz/openbmc_project/inventory/enumerate  | grep -A3 gv
gives
xyz/openbmc_project/inventory/system/chassis/motherboard/gv100card0
xyz/openbmc_project/inventory/system/chassis/motherboard/gv100card1
xyz/openbmc_project/inventory/system/chassis/motherboard/gv100card2
xyz/openbmc_project/inventory/system/chassis/motherboard/gv100card3


Support for auto-annotate ES classes

I would expect this to work:
var di = require('didi');

class Car {
    start() {
        console.log('success!');
    }
}

var module = {
    'car': ['type', Car],
};

var injector = new di.Injector([module]);
injector.invoke(['car', function (car) {
    car.start();
}]);

But what I get is this error:
node_modules\didi\dist\didi.js:125
  return match[1] && match[1].split(',').map(function (arg) {
              ^

TypeError: Cannot read property '1' of null
    at parse (c:\z\github\nikku\tmp\node_modules\didi\dist\didi.js:125:15)

The problem seems to be with annotation.js, where the toString of the class is expected to include this regex:
 /^function\s*[^(]*\(\s*([^)]*)\)/m;
But the toString is the class definition above and thus does not comply to the regex.

Feature implemented via https://github.com/nikku/didi/commit/99bccd5912e523f417c8599180972d68ff6eee16.
Give it a try.

I've tried it, but it does not seem to work with<EMAIL_ADDRESS>\node_modules\didi\dist\index.cjs.js:55
  return match[1] && match[1].split(',').map(function(arg) {
              ^

TypeError: Cannot read property '1' of null

If I add Car.$inject = [];  it does work.

How does fn.toString() look like?

I got it. You're not specifying a constructor.

Fixed via https://github.com/nikku/didi/commit/72f780b3ec172b8303ad9f9b6fb49221973195d8.

Great! Works like a charm


Button to copy query as code in dataframe view

Add a button to the dataframe view that allows one to copy the current query as code (either Rust or Python).
This should be fairly straightforward now that everything is baked into the new QueryExpression (I'm pretty much imagining a QueryExpression::to_{rust,python}_string().

Duplicates #7462


Add publish on tag push

Please add the OAUTH_ACCESS_TOKEN and OAUTH_REFRESH_TOKEN in the secrets on this repo. Ref: https://medium.com/evenbit/publishing-dart-packages-with-github-actions-5240068a2f7d. Enable github actions if you haven't. Once you are ready to publish a new version, simply tag as v1.1.4 etc.

Thank you. My problem is that it's difficult to push data to pub due to national restrictions, need VPN.

Yes. Hopefully this would help as the publishing would be controlled by GitHub tags

ok.


✨ Website / python pyos meta data bug in listing package maintainers

Currently we use the code in this repo to create a new, updated package.yml file containing the newest pyos packages and listing the packages name, github repo location, documentation and doi information.
Currently if you look at the website, you will notice that in many instances there is only one name and also sometimes rather than the actual name, the yaml file just says "name".

I believe this is a combination of two issues

i think the code in this repository is sometimes returning a missing name or the word "name" as the maintainer name.
i believe that we will wnat to use the packages.yml file produced via the PR here which should generate a maintainer item.

once this is completed, we can update the code for the website here: (we will need to update the packages-grid include file

note because #6 was merged about - now the next step of this is to update the code in the pyopensci.github.io repository here
Fix this liquid template to parse through the maintainer names and add them to each card on the website. will open a issue in the repo now.

this is being worked on now via https://github.com/pyOpenSci/pyopensci.github.io/pull/172

this has been fixed! closing it


Feature-Policy is now Permissions-Policy

Per MDN: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy
Looks like this got renamed a while back; we should probably flag a MEH is a site reports Feature-Policy.

Hello, Is this issue open?

Looks open to me. Are you asking whether someone has been assigned to it? The answer to that is  no; if you're interested in it, I'm happy to assign you.

That was indeed the subquestion, I'd be happy to look at it!

Yes, feel free! I've assigned you.


Consider adding more file formats support

[x] .fbx : Must have https://github.com/f3d-app/f3d/issues/37

Formats to consider sorted by reddit upvotes:

[ ] .usd 9: https://github.com/f3d-app/f3d/issues/780
[x]  .dae (collada) 7
[ ]  .x (directx) 7
[ ] Parasolid (.x_b, .x_t) 7
[ ] ACIS (.sat) 7
[ ] .3DXML 7
[ ] .blend 7
[ ] .3mf 4
[ ] .jt 3
[ ] .ipt/.iam 3
[ ] .dwg 3
[ ] .ifc 3
[ ] Navisworks .nwd 2
[ ] .dwx/.dwfx 2
[ ] .ma 2
[ ] .ztl/.ztr 2
[ ] vdb 2 : supported by VTK ! #181
[ ] .skp 1
[ ] .wire 1
[ ] Revit formats RVT, RFA, RTE, RFT. 1
[ ] e57. 1
[ ] .ztl 1
[ ] .ma 1
[ ] .3dxml 1
[ ] .pcd 1
[ ] .las 1

https://gitlab.kitware.com/f3d/f3d/-/issues/219

I am voting for  VDB as well, it is super common in VFX pipelines.

added the vote and moved it up. We would need someone willing to work with OpenVDB. library.
FYI @Meakk

Also please consider supporting more point cloud formats.
.pts is already available, but tbh I've never come across one single pts file. e57, ply, and even simple xyz are much more common.

Hi,
.ply is supported already. .xyz has no real standard for point clouds. Ill take a look at e57

Would be amazing to have ztl, maya ascii, 3DXML, and the ability to open 3dPDF files albeit that may be out of the scope of this project

Pretty much all proprietary formats, i'd not get my hopes up.

https://drawing.wiki/skills/whats-the-difference-between-ztl-and-zpr-files-in-zbrush/
https://autodeskmaya.fandom.com/wiki/ASCII_File (may be doable since it is text based)
https://en.wikipedia.org/wiki/3DXML

I figured ztl was a stretch, and the models will be super heavy too generally. 3DXML is supported by many apps so I assumed it wasn't but I guess not. Some other software imports maya ascii too for example Zbrush

+1 for .3mf
I would also very much like to se support for .3mf as all major software packages around 3D print add it recently. It is supposed to have some advantages over .stl, see e.g. https://blog.prusa3d.com/3mf-file-format-and-why-its-great_30986/ .

Added your vote and a note for vdb (which has its own issue : #181 )

USD is pretty essential. It will very soon be the core 3d format imo

Added your vote @crafthive ! I hope someone who knows the format could go ahead and implement support,

+1 for USD  is the upcoming standard.

also - I think opensource, multi-application formats should get priority over proprietary/application specific formats

Added @H4kunaM4tata  vote for .3mf

@mrpurest : tbh it is more about finding contributors willing to add support for specific file formats

@mrpurest : added your .usd vote

Thank you @mwestphal , happy 3D printing.

For anyone following this, please note that since plugins are now supported, anyone can develop their own plugin, as @YangShen398 did for abaqus !

added a few votes for USD as it was mentionned on reddit multiples times

more use votes, we definitely should consider it.

Hi @OloOcki !

CityGml is already supported :)
I've added pcd and las to the list.

Added a .3mf vote from reddit

Hi @OloOcki !
* CityGml is already supported :)

* I've added pcd and las to the list.

Hi @mwestphal excellent! I've missed it! I'll update the list of CityGML-supported viewers, then!  Awesome CityGML
Thank you for adding!

Thanks !
TBH it's all thanks to VTK, that you may want to add in your list too, as a library.

USD support coming soon.

Is support for MaterialX within USD important?

Added two ifc votes

Please support extension ( blender + maya )

I've added your .blend vote @MostFull , what is Maya format specifically?

.ma
في الجمعة، ٤ أغسطس ٢٠٢٣, ٧:١٦ م Mathieu Westphal @.***>
كتب:

I've added your .blend vote @MostFull https://github.com/MostFull ,
what is Maya format specifically?
—
Reply to this email directly, view it on GitHub
https://github.com/f3d-app/f3d/issues/38#issuecomment-1665868510, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ACS7GPTF5YUXY35NDVUMMQ3XTUN6LANCNFSM5H5Z3ADA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Added

Thank you for your efforts. I would like to point out that some formulas are repeated twice in the first comment. For example, (ma) has two votes, and another (ma) has two votes. Why are there two (ma) ?

Good point! Ive combined them!

3MF, please

Added

Open Cascade BRep format could be useful for CAD users working with OCC-based procedural generation (eg. cadquery, build123d) to F3D pipelines.
example file here: https://github.com/tpaviot/pythonocc-demos/blob/master/assets/models/Motor-c.brep

.brep added

support for .3mf , that would be awesome

.3mf format vote added

USD format support added!

Please support 3mf Format

3mf vote added

Dedicated isssue created for 3mf, blend and X support!

X format support just merged in master (rely on the assimp plugin)

VDB support added, please try the last nightly:
https://github.com/f3d-app/f3d/releases/tag/nightly

3mf and x support available in the nightly release!
https://github.com/f3d-app/f3d/releases/tag/nightly

My votes for 3dxml and jt, though I understand that as semi-proprietary formats, they're both long shots. Just a heads-up that the list in the issue contains both .3DXML and .3dxml, which I assume to be the same.
Some background on the formats:
The 3DXML file format is mostly officially documented here.  Unfortunately, it can also sometimes use some proprietary compression and encoding on .3DREP files that contain the actual geometry data. I assume that would require some reverse engineering, which is probably beyond the scope of this project.
When that compression is not present, however, you've got some plain ascii xml files, which should be supportable. There is an open source implementation with GLC_lib and GLC_Player, although it's pretty janky in my experience.
Some discussion of people trying to implement it is here and here, which provides some background, but I think the official documentation is the most helpful.
I haven't tried working with JT directly, but a colleague of mine has, and while the format has a public and open specification, it is extremely non-trivial to implement and not fun. We have opted to use the proprietary and licenced JT Open Toolkit, which is of course not an option here.
It looks like there are some open source projects that try to work with the file format, but I don't know how usable they are, see dxjt_toolkit and oce-jt.

Added your votes to the list.
Thank you for the links.
Note that it's still possible to open-source a plugin using a proprietary library. It has already been done for the ODB format: https://github.com/YangShen398/F3D-ODB-Reader-Plugin

add 3dm

I do vote for 3DM support.

Added a .las vote after discussing with  a potential user :)

Revit families (.rfa) would be nice.

@runxel : I've added your vote.

@Diegovsky @Nokse22 I've added the .skp format

Adding an .ifc vote from discord

+1 for 3MF (see https://github.com/Nokse22/Exhibit/issues/39)

+1 for 3MF (see https://github.com/Nokse22/Exhibit/issues/39)

It's already supported by f3d

I confirm the 3MF is already supported, by the assimp plugin.

+1 for IFC.
It will be helpful for architects, Bim managers and plant conception
I don't have the competences myself, but I saw some open source library that can help translate 3D data from IFC to other format (step for example)
IFCopenshel and IFCplusplus  for example.

Added an .ifc vote.

+1 for .laz

Added .laz votes

Added .spz Gaussian Splatting format. See https://github.com/nianticlabs/spz

Could you add .ply gaussian splats?

Could you add .ply gaussian splats?

That's possible in theory, but it may be tricky to distinguish between regular PLY and gaussian splats.

Could you add .ply gaussian splats?

That's possible in theory, but it may be tricky to distinguish between regular PLY and gaussian splats.

What about Magic Bytes/Numbers? (better than relying on file extensions)
e.g. libmagic: https://github.com/file/file

3dgs ply files are like normal point cloud ply files, but with covariance matrices and spherical harmonics for each vertex

Actually this approach even allows you to restore/recover missing or wrong extensions. This is an additional benefit.


Relocate breaking Go SDK change out of template

Original pr https://github.com/apache/beam/pull/15374 edited the template rather than the 2.33.0 section. Already fixed in master https://github.com/apache/beam/pull/15574, but the cherry pick would not be clean.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

R: @udim


Update translations needed for 1.2

We need a better way to automate flagging up when translation updates are needed.
In the meantime, here's a list of what's needed for 1.2.
First, to get a list of locale files that have changed since the last stable release, 1.1.3, you can run:
git diff --name-only 1.1.3 1.2.0-beta.1 | grep locales

<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
To get the actual differences:
for x in `git diff --name-only 1.1.3 1.2.0-beta.1 | grep locales`; do  git diff 1.1.3 1.2.0-beta.1 $x; done

diff --git<EMAIL_ADDRESS><EMAIL_ADDRESS>index 309f9db8..9fe4ef33 100755
---<EMAIL_ADDRESS>+++<EMAIL_ADDRESS>@@ -22,7 +22,8 @@
             "color": "Color",
             "position": "Position",
             "enable": "Enable",
-            "disable": "Disable"
+            "disable": "Disable",
+            "upload": "Upload"
         },
         "type": {
             "string": "string",
@@ -197,6 +198,8 @@
         "flow_plural": "__count__ flows",
         "subflow": "__count__ subflow",
         "subflow_plural": "__count__ subflows",
+        "replacedNodes": "__count__ node replaced",
+        "replacedNodes_plural": "__count__ nodes replaced",
         "pasteNodes": "Paste flow json or",
         "selectFile": "select a file to import",
         "importNodes": "Import nodes",
@@ -212,6 +215,9 @@
         "groupCopied_plural": "__count__ groups copied",
         "groupStyleCopied": "Group style copied",
         "invalidFlow": "Invalid flow: __message__",
+        "recoveredNodes": "Recovered Nodes",
+        "recoveredNodesInfo": "The nodes on this flow were missing a valid flow id when they were imported. They have been added to this flow so you can either restore or delete them.",
+        "recoveredNodesNotification": "
Imported nodes without a valid flow id

They have been added to a new flow called '__flowName__'.
",
         "export": {
             "selected":"selected nodes",
             "current":"current flow",
@@ -226,13 +232,19 @@
         },
         "import": {
             "import": "Import to",
+            "importSelected": "Import selected",
+            "importCopy": "Import copy",
+            "viewNodes": "View nodes...",
             "newFlow": "new flow",
+            "replace": "replace",
             "errors": {
                 "notArray": "Input not a JSON Array",
                 "itemNotObject": "Input not a valid flow - item __index__ not a node object",
                 "missingId": "Input not a valid flow - item __index__ missing 'id' property",
                 "missingType": "Input not a valid flow - item __index__ missing 'type' property"
-            }
+            },
+            "conflictNotification1": "Some of the nodes you are importing already exist in your workspace.",
+            "conflictNotification2": "Select which nodes to import and whether to replace the existing nodes, or to import a copy of them."
         },
         "copyMessagePath": "Path copied",
         "copyMessageValue": "Value copied",
@@ -532,6 +544,7 @@
             "sortAZ": "a-z",
             "sortRecent": "recent",
             "more": "+ __count__ more",
+            "upload": "Upload module tgz file",
             "errors": {
                 "catalogLoadFailed": "
Failed to load node catalogue.

Check the browser console for more information
",
                 "installFailed": "
Failed to install: __module__

__message__

Check the log for more information
",
@@ -708,6 +721,12 @@
                 "committerTip": "Leave blank to use system default",
                 "userName": "Username",
                 "email": "Email",
+                "workflow": "Workflow",
+                "workfowTip": "Choose your preferred git workflow",
+                "workflowManual": "Manual",
+                "workflowManualTip": "All changes must be manually committed under the 'history' sidebar",
+                "workflowAuto": "Automatic",
+                "workflowAutoTip": "Changes are committed automatically with every deploy",
                 "sshKeys": "SSH Keys",
                 "sshKeysTip": "Allows you to create secure connections to remote git repositories.",
                 "add": "add key",
diff --git<EMAIL_ADDRESS><EMAIL_ADDRESS>index 1ba4e53b..081b0c7a 100644
---<EMAIL_ADDRESS>+++<EMAIL_ADDRESS>@@ -19,6 +19,8 @@

Inputs

+
delay number

+
Sets the delay, in milliseconds, to be applied to the message. This option only applies if the node is configured to allow the message to override the configured default delay interval.

reset

If a message is received with this property, any timeout or repeat
         currently in progress will be cleared and no message triggered.

@@ -35,6 +37,7 @@
     act as a watchdog timer; only sending a message if nothing is received within the
     set interval.

If set to a string type, the node supports the mustache template syntax.

+
The delay between sending messages can be overridden by msg.delay if that option is enabled in the node. The value must be provided in milliseconds.

If the node receives a message with a reset property, or a payload
     that matches that configured in the node, any timeout or repeat currently in
     progress will be cleared and no message triggered.

@@ -42,6 +45,6 @@
     is reset by a received message.

Optionally, the node can be configured to treat messages as if they are separate streams,
     using a msg property to identify each stream. Default msg.topic.

-
The status indicates the node is currently active. If multiple streams are used the status
+
The status indicates the node is currently active. If multiple streams are used the status
     indicates the number of streams being held.

 </script>
diff --git<EMAIL_ADDRESS><EMAIL_ADDRESS>index e6d5da06..eb623ce2 100755
---<EMAIL_ADDRESS>+++<EMAIL_ADDRESS>@@ -320,6 +320,7 @@
             "h": "Hours"
         },
         "extend": " extend delay if new message arrives",
+        "override": "override delay with msg.delay",
         "second": " send second message to separate output",
         "label": {
             "trigger": "trigger",

@kazuhitoyokoi FYI - if you are able to provide the above updates in the next few days, that would be great.

Do you want to close this ? or should we leave open for other languages ?

The priority was the Japanese translations. We know most of the others have fallen behind, but in absence of anyone to get them updated, this issue won't reflect the full backlog of work to be done.
Will close this one and we need to come up with a better way to track when updates are needed. The i18n.nodered.org site has fallen behind and needs more work to be useful.


Clean up the "dark" QPalette

Right now it looks "good enough", but some things are inconsistent, and it's just a long list of hard-coded magic numbers.
The QPalette for the console widgets might also need to be set separately (instead of directly as a stylesheet property).
Original dark theme: https://gist.github.com/QuantumCD/6245215

Possible palette ideas:
http://paletton.com/#uid=54H0I0kkElTa5xqfmrbpSgFvibg
Also: maybe look at linux's built-in system palettes?
Original blog post about the current style system:
https://www.qt.io/blog/2012/10/30/cleaning-up-styles-in-qt5-and-adding-fusion
The source for the old styles (e.g. motif, plastique) that were removed when fusion was added can be found here:
https://github.com/qt/qtstyleplugins
https://code.qt.io/cgit/qt/qtstyleplugins.git/
Qt stylesheet reference:
https://doc.qt.io/qt-5/stylesheet-reference.html
Some sample styles from the Qt wiki:
https://wiki.qt.io/Gallery_of_Qt_CSS_Based_Styles

Color Palette by Paletton.com
Palette URL: http://paletton.com/#uid=54H0I0knCkUe7uoj-p1s-g9-UaJ
*** Primary color:
shade 0 = #54226F = rgb( 84, 34,111) = rgba( 84, 34,111,1) = rgb0(0.329,0.133,0.435)
shade 1 = #8A5EA2 = rgb(138, 94,162) = rgba(138, 94,162,1) = rgb0(0.541,0.369,0.635)
shade 2 = #6A3885 = rgb(106, 56,133) = rgba(106, 56,133,1) = rgb0(0.416,0.22,0.522)
shade 3 = #3C0D56 = rgb( 60, 13, 86) = rgba( 60, 13, 86,1) = rgb0(0.235,0.051,0.337)
shade 4 = #260339 = rgb( 38,  3, 57) = rgba( 38,  3, 57,1) = rgb0(0.149,0.012,0.224)
*** Secondary color (1):
shade 0 = #952748 = rgb(149, 39, 72) = rgba(149, 39, 72,1) = rgb0(0.584,0.153,0.282)
shade 1 = #D87996 = rgb(216,121,150) = rgba(216,121,150,1) = rgb0(0.847,0.475,0.588)
shade 2 = #B24566 = rgb(178, 69,102) = rgba(178, 69,102,1) = rgb0(0.698,0.271,0.4)
shade 3 = #730C2B = rgb(115, 12, 43) = rgba(115, 12, 43,1) = rgb0(0.451,0.047,0.169)
shade 4 = #4C0017 = rgb( 76,  0, 23) = rgba( 76,  0, 23,1) = rgb0(0.298,0,0.09)
*** Secondary color (2):
shade 0 = #2B2B75 = rgb( 43, 43,117) = rgba( 43, 43,117,1) = rgb0(0.169,0.169,0.459)
shade 1 = #6A6AA9 = rgb(106,106,169) = rgba(106,106,169,1) = rgb0(0.416,0.416,0.663)
shade 2 = #43438C = rgb( 67, 67,140) = rgba( 67, 67,140,1) = rgb0(0.263,0.263,0.549)
shade 3 = #16165A = rgb( 22, 22, 90) = rgba( 22, 22, 90,1) = rgb0(0.086,0.086,0.353)
shade 4 = #08083C = rgb(  8,  8, 60) = rgba(  8,  8, 60,1) = rgb0(0.031,0.031,0.235)
Generated by Paletton.com (c) 2002-2014


HDDS-10346. Make test cases in TestSstFilteringService independent

What changes were proposed in this pull request?
Check if it is possible to make test cases in TestSstFilteringService independent of execution order.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-10346
How was this patch tested?
Tested it locally and in CI build.

Thanks @raju-balpande for the patch, @hemantk-12, @myskov for the review.


x/review/git-codereview: can't "git change" to multi-commit branch

I have a multiple commit branch, which can be seen at https://go-review.googlesource.com/c/gofrontend/+/281533.  The change that created that branch has now been submitted, by pressing the "Submit" button in Gerrit.  Now, in my git workspace, I am trying to get back to the branch to adjust the remaining commits.  I used to be able to do that via git change embed (I used embed with the original git change command.)  Now, however, I get
> git change embed
git-codereview: cannot change: found pending rebase or sync

I'm using revision 027ac86e514dbb1000ae4ec5b282f39af4d2f7a3 of golang.org/x/review.  What should I do?
CC @rsc @mdempsky

From looking at the sources, it appears that the problem is that git rev-parse --abbref-ref REBASE_HEAD prints out REBASE_HEAD rather than getting an error.  I guess I need to figure out why that is happening....  git status doesn't show anything interesting.

From looking at the sources, it appears that the problem is that git rev-parse --abbref-ref REBASE_HEAD prints out REBASE_HEAD rather than getting an error.  I guess I need to figure out why that is happening....  git status doesn't show anything interesting.

OK, I was able to fix this (I hope) using git reset HEAD.

OK, I was able to fix this (I hope) using git reset HEAD.


adding list of components with component prop

[x] I have followed (at least) the PR section of the contributing guide.

added a list of components with the component prop to the composition.md file
at /docs/src/pages/guides/composition/composition.md
Issue  #22001

@oliviertassinari I have created a list in the Markdown file.  looks like one of the tests failed.  Not sure if that test is appropriate to document file.

@Maxgit3 Thanks for looking into it, I have updated the wording to keep it simpler; I think that the idea should be to communicate that it's a systematic solution.


RFP: RetroPGF List Creation UI

Foundation Mission (RFP) – RetroPGF List Creation UI

Proposed Foundation Mission (RFP): RetroPGF List Creation UI
S4 Intent: Governance Accessibility
Proposal Tier: Ember
Baseline grant amount: 20k OP
Should this Foundation Mission be fulfilled by one or multiple Alliances: One
OP Labs or Optimism Foundation Sponsor: Jonas (gh: @JSeiferth, TG/Discord: @jonassft)
Submit by: September 4th, 2023
Selection by: September 11th, 2023

How will this Foundation Mission (RFP) help accomplish the above Intent?
Retroactive Public Goods Funding (RetroPGF) Round 3 will take place this fall and will distribute 30M OP to reward contributions that have supported the development and adoption of Optimism.
This mission will create an application that allows badgeholders (voters in RetroPGF) to create Lists, a new tool for vote sharing and by doing so contribute to a more accurate evaluation of projects and the overall success of RetroPGF 3.
What are Lists?

A List contains a set of projects chosen from the total set of RetroPGF applicants together with a suggested OP allocation for each project.
Each List should reference some methodology for allocating OP to each project based on the creators expertise and evaluation of relevant data.
Only badgeholders are allowed to create Lists.
Lists will facilitate context sharing among badgeholders, and enable badgeholders to easily leverage each other's proposed votes.

In the previous round of RetroPGF, badgeholders started sharing their proposed votes to learn from each other's expertise in different areas. In round 3, we’re introducing Lists as a more powerful tool to facilitate that sharing of context, and enable badgeholders to easily leverage each other's proposed votes.
The RetroPGF Voting application will allow badgeholders to discover, view and interact with Lists (see screenshot of designs below). This mission will enable badgeholders to create the Lists that are surfaced in the RetroPGF Voting application.
How Lists are presented to users

What is required to execute this Foundation Mission (RFP)?
Completing this Mission requires:

Outlining your proposed solution to allow badgeholders to create Lists
Building a frontend that enables badgeholders to create Lists by leveraging EAS for onchain attestations and posting metadata on IPFS. The frontend should be fully open-source and should allow for future iterations of the functionality.
Hosting and managing the application infrastructure while RetroPGF 3 is ongoing.

Core functionality of the application
Enable badgeholders to create Lists, the following steps are core to this user journey:

Input relevant metadata of a List (Name, description, impact evaluation description, impact evaluation link)
Filling in the contents of a List by choosing projects and inputting how much OP each project should receive
Posting the List onchain via EAS and associated metadata
View created Lists

Relevant checks will need to applied to the creation of Lists, such as char limits and other limitations (e.g. the OP allocated among projects can't exceed the total round OP allocation.)
Technical Architecture and implementation

Query project data: Ethereum Attestation Service (EAS) is used to query existing onchain information relating to entities and their RetroPGF 3 application (e.g. projects). This will be relevant to display project names and profile pictures, as well as referencing projects in List attestations. Relevant schema information and indexer will be provided once the proposal has been accepted.
Posting Lists: Ethereum Attestation Service (EAS) is used to post the contents of a List onchain and reference the relevant metadata. Relevant schema information and indexer will be provided once the proposal has been accepted.
The application should be live and usable by Oct 14th 2023, you will host the application yourself and maintain it until March 2024.
Everything that you build should be open-source under MIT license and should allow for future iterations of the functionality.

You can find the EAS & Metadata schema for Lists here
What milestones will help the Collective track progress towards completion of this Foundation Mission (RFP)?

Specification for implementation, design approach, and architecture
Open-source code repository to observe progress over time
Launch of the application

How should badgeholders measure impact upon completion of this Mission (RFP)?

Number of Lists created via the application
Qualitative feedback on the List creation experience by badgeholders

Application instructions
To apply for this RFP, please complete the form in the expandable section below and leave your response as a comment on this issue thread. Submissions will be open until June 28, at which time the Foundation will review all submissions and select one individual/team to complete the work defined here.

Submission form
Copy the entire application below and leave a comment on this issue with your answers completed. A representative from the Optimism Foundation may reach out using the contact info provided to request more information as necessary.
Foundation Mission (RFP) Application
Please verify that you meet the qualifications for submitting at the above Tier

Alliance Lead: Please specify the best point of contact for your team
Contact info:
L2 recipient address:
Please list the members of your Alliance and link to any previous work:

Read more about Alliances here

What makes your Alliance best-suited to execute this Mission?

[...]
[...]

Please describe your proposed solution based on the above Solution Criteria (if applicable):

[...]
[...]

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work:

[...]
[...]

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

[...]
[...]

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

[...]
[...]

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)

[...]

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

[ ] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
[ ] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
[ ] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual
[ ] I confirm that I have read and understand the grant policies
[ ] I understand that I will be expected to following the public grant reporting requirements outlined here

-- end of application --

Hi, @JSeiferth  your image is inaccessible again

@Chomtana updated, try now

@JSeiferth @bdresser
Only badgeholders are allowed to create Lists.
Shouldn't lists be created by anybody to crowdsourcing communities to help badgeholders?

Hi, @JSeiferth
I have some questions about this RFP

Are "Edit distribution" from the screenshot and delete list included in this RFP scope?

If so, does edit distribution means only changing the OP allocation of the already set projects or also adding and removing projects?

On the screenshot, it’s shown the address of who created the list. But can the badgeholder choose if they want to show their address or not?
On the same note, the Lists are not the actual votes from the list creator as replied here. Can a badgeholder create multiple lists or just one per badgeholder?
Lastly, it seems like this RFP is a blocker to #104 Phase 2. This means we should have close communication with both selected teams from that RFP to align all the 3 teams' delivery dates, correct?

@JSeiferth is this RFP still open ? Can we still propose our solution? Thanks

RetroPGF Voting Lists Supermodular Foundation Mission Application

Team Lead: Kevin Owocki
Contact info<EMAIL_ADDRESS>| Owocki#1337
L2 recipient address: 0x00De4B13153673BCAE2616b67bf822500d325Fc3

Team members

Kevin Owocki - Community Lead
Carl Barrdahl - Engineering Lead
Octavian Todirut - Design Lead
Cristina Lare - Front End Engineer
Carey Murdock - Ops & Admin

Previous Work
We are the team behind Supermodular, the venture studio that launched Gitcoin. We are focused on doing lean 0 to 1 build outs in the regen ecosystem.

Gitcoin - which has funded $50m worth of ecosystem public goods. https://impact.gitcoin.co

A few other things we’ve built:

PGN bridge - Bridge for the Public Goods Network (Op Stack L2)

https://bridge.publicgoods.network

quadratic lenster - Quadratic tipping via quadratic funding rounds on Lens Protocol

https://gov.gitcoin.co/t/quadraticlenster-xyz-launch-wrap-up/15962

funding.social - See who youre following on lens + who they contribute to on Gitcoin

https://funding.social

Gitcoin Grants data visualizer

https://twitter.com/owocki/status/1658103631500161024

Sybil-resistant faucet

https://twitter.com/owocki/status/1671581682925965312

GiveGratitude - a tool for easily minting hypercerts

https://givegratitude.io

QuadHoney - an experimental mobile Quadratic Voting webapp built for ETHDenver

https://qf-flash.vercel.app

Our work is open-source: https://github.com/supermodularxyz

What makes your Alliance best-suited to execute this Mission?
We are already building the Discovery & Voting for RetroPGF it would make sense to create the lists in the same app.
We're already building much of what is required in this RFP:

Query Projects
Project search
Allocation Form (how much OP for each project)
View Lists

We have already made good progress in the RFP and will have much of the functionality in place by September 17th.
You can check our progress here:
https://retro-pgf.vercel.app
https://github.com/supermodularxyz/OP-RetroPGF
Read more about why we are a great fit for this project:
https://github.com/ethereum-optimism/ecosystem-contributions/issues/104#issuecomment-1662770062
Please describe your proposed solution based on the above Solution Criteria (if applicable):
Frontend
We will have much of the frontend in place:

Connect wallet
Client-side verification of badgeholders
View Lists

A Create List page will be created and a link placed either in the Links page or in the navbar (possibly both).
The Create List page looks similar to View List page but with input fields to enter the list data.
A search input allows the user to search for projects and add to the Allocation form. Searching for projects is already implemented as part of the Discovery & Voting. The allocation form is similar to the Edit Distribution and Ballot Review in RetroPGF Discovery & Voting. Thus the badgeholders are familiar with the UI.
Once the form has been filled out the badgeholder click Save List button and signs a message in the wallet. When the list has been created the user is shown a success message.

Backend
The backend receives the created list and the signed message. This signature is verified to make sure the badgeholder did in fact create the list and ensure the authenticity.
The backend uploads the list data to IPFS and creates an EAS Attestation.
OpenZeppelin Relayer is used to pay for the gas for creating the attestations. This gives us some benefits:

Badgeholder doesn't need to pay gas
Better security because we don't expose the wallet private key
A dashboard where we can see the balance and email notifications if funds drop below 0.1 ETH

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work:

Implement Create List page with form

Inputs for name, description, impact evaluation description & link
Allocation form (we're already building this)
Input to search for projects (we're already building this)

Create backend endpoint

API endpoint to receive list and a signature
Verify signature
Upload list data to IPFS
Create attestation

Testing & QA

Milestone
Done by

Specification
2023-09-20

Create List page
2023-09-24

Backend
2023-10-01

Testing & QA
2023-10-08

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

We will have a specification for implementation, design approach, and architecture by 24 September
We will have an open-source code repository to observe progress over time (already done)
We will launch the application on 08 October

Please list any additional support your team would require to execute this mission (financial, technical, etc.):
Check-ins every other week to do demos/get feedback.
Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant:
We do not need upfront capital to do this.

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:
[x] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
[x] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
[x] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual
[x] I confirm that I have read and understand the grant policies
[x] I understand that I will be expected to following the public grant reporting requirements outlined here

Hey, @JSeiferth this is a PoC I've worked on to make sure I understand the concept. It would help a lot to get your input! Thanks
https://www.loom.com/share/e9d56af1b5564b9292730bdee4a278f5?sid=5b066757-4504-4edc-9e13-7ddd490d6792

@JSeiferth proposal submission has been extended to September 4th right?

Please verify that you meet the qualifications for submitting at the above Tier

Alliance Lead: Freshelle

Contact info: Zeptimus will handle comms: @zeptimusq (Telegram)

L2 recipient address: 0xc8d65e1bd67f16522e3117b980e1c9d2caeb9dc3 (generalmagic.eth)

Please list the members of your Alliance and link to any previous work:

@pourcheriki - Developer. More info: Github Lead Front-End Developer at Giveth. Cherik has been leading the front-end design on a variety of products and features in the Giveth Galaxy for the last 2 years.

@markoprljic - Design lead. Head of Design and Business Developer at General Magic. “Magic Marko” is a top notch designer and has been practicing his art on web2 and web3 projects for over a decade.

@mhmdksh - Devops. He's managing servers and working with devst to enhance processes, and automate deployment procedures.

@ZeptimusQ - Comms. Transparency and accountability advocate. A passionate representative focused on decentralized governance.

@thegrifft - Advisor. Co-founder of Giveth, Commons Stack, General Magic, Dappnode. Optimism Steward.

@moe_nick - Advisor. Products & Fintech Enthusiast. PM for https://giveth.io, also PMing the Pairwise project ex-MyDigipay, ex-Tadbirpardaz, ex- Finnotech

We will be collaborating with various members of the Pairwise team as needed. Their expertise and insights will be invaluable in ensuring the success and efficiency of our proposed solution.

Read more about Alliances here

What makes your Alliance best-suited to execute this Mission?
Our Alliance is uniquely positioned to execute this mission due to our extensive experience and proven track record.

Years of Web3 Public Goods Experience: We have designed and developed Giveth, the longest running donation platform in the web3 space. Giveth has been fostering community and facilitating donations for public goods since 2018 and its current DApp has similar features such as project discovery, project pages, and voting on projects (via GIVpower).
Diverse Application Experience: Besides Giveth we have worked on a wide variety of other projects across the space, including the Conviction Voting on Gitcoin, Gitcoin’s new Grants Stack and Allo Protocol, ENS Merch Shop, the TE Academy Fundamentals course, and the TEC Design Dashboard.
Our RetroPGF Community Connections: We are uniquely positioned to execute on this proposal as we can easily coordinate with two teams already working on RetroPGF this round.

Pairwise is currently in active development, and we are excited to coordinate with that team to use their simple UX as a fun method to create standard lists. The team has been researching RetroPGF voting for the last several months and will be helpful in advising our work.
RetroPGF community marketing is well underway, we have been advocating and marketing the use of RetroPGF online via twitter and in IRL events during EthCC and ETHBarcelona. This project owns retropgf.com and we would plan to host the voting application there.

RetroPGF Experience: Our team has participated in RetroPGF from every angle and we have all benefited greatly from it, and we want to give back! We have seen every side of RetroPGF and truly appreciate and understand the challenge.

Daniele had 2 grants in RetroPGF2 (delegation.tools and the DAppNode Optimism Package)
Giveth was a recipient of RetroPGF1 & 2
Griff was a badgeholder in the last round.

We are excited to apply our unique experience to become a part of one of the most important Public Goods experiments in web3.
Please describe your proposed solution based on the above Solution Criteria (if applicable):
We are creating an interface that encompasses all the categories and projects selected for RetroPGF3. Users will have the ability to create their own lists based on these categories, curating collections of projects. In our interface, citizens can create up to five lists that they can share and edit. Citizens will allocate a percentage of the budget to specific categories and then to individual projects. This allocation can be done manually, and the system will seamlessly integrate with Pairwise.
Categorization of Projects into “Collections”:

We will create special categorized lists that we will call categories, these collections are projects with the most similarities. And those will include multiple projects that have applied for RetroPGF. This will facilitate easier navigation and decision-making for voters.

To realize this vision, we are committed to creating an open, transparent process to classify the projects. We'll engage projects to collect additional data, publicly share all collected data, conduct community reviews of our categorizations, and actively collaborate with the Pairwise team to integrate with their application. Our focus on strong project categorization, combined with the effective integration of technology and community engagement, aims to enhance the overall user experience and the efficacy of the voting process.

Integration with Pairwise:

We will collaborate with the Pairwise team to create specific categories for project lists. This will allow voters to submit their lists on the dapp we create or upload them directly from Pairwise. Our application will not depend on Pairwise's success but will integrate seamlessly with it if they succeed.

We will work side-by-side with the Pairwise team to categorize the projects into categories, and validate those categorizations with the community.

Public or Private Submission of Lists:

Citizens will have the option to submit their lists publicly or record and share their evaluations privately in a CSV file, or in the web-app if they get back and signed in again..
Citizens will be able to create custom lists or use categories to submit lists publicly .

Integration with EAS for On-chain Attestations and IPFS Metadata Posting:

A pivotal feature of our solution is its integration with the Ethereum Attestation Service (EAS) for on-chain attestations. Ensuring authenticity and transparency of the lists created by citizens.

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work:
Technical work:

Project Kickoff and Planning (1 day): We will begin with a project kickoff meeting to align our team with the mission's goals and requirements. This will be followed by a detailed planning phase where we will outline the project's scope, define roles and responsibilities, and establish key milestones and deadlines. It would be very helpful to have a Product owner from Optimism with us for this 2 hour call.
Design and Architecture (1 week): During this phase, we will design the system architecture and user interface based on the provided designs and user stories. We will also draft a specification for collecting and storing user-curated project lists and their impact evaluations, ensuring seamless integration with EAS for on-chain attestations and IPFS for metadata posting.
Development of Core Features (7 weeks): This phase will involve the development of core functionalities such as project discovery, user-curated project lists, and voting infrastructure. We will also construct a RESTful API or GraphQL backend that handles user operations and integrates with the RetroPGF Protocol APIs, IPFS, and Ethereum Attestation Service (EAS).
Testing and Quality Assurance (2 weeks): We will conduct thorough testing of all features and functionalities to ensure they work as expected and provide a smooth user experience. This will include unit testing, integration testing, and user acceptance testing.
Launch of Project Discovery Feature (During the QA phase): We will launch the project discovery feature, enabling users to explore all nominated projects and view project profiles.
Launch of List Creation Feature (During the QA phase): Concurrently with the project discovery feature, we will launch the voting feature, allowing citizens to discover lists, and allocate and submit Ballots.
Maintain, Support and Improve (Until March 2024): Post-launch, we will provide continuous maintenance and support, ensuring the application runs smoothly and any issues are promptly addressed. We will continue to work on this application expecting to be rewarded via RetroPGF.
Feedback and Iteration (Ongoing): Throughout the project, we will actively seek feedback on the forums from the community and make necessary adjustments and improvements to our solution.

Categorization work:

Project kickoff and planning (1 day): Same as above.
Create and review a deform (3 days): This will be an optional form that projects can use to give us extra information that will help us categorize the projects.
Distribute the categorization deform (Ongoing): We will reach out to projects to ensure they have an opportunity to help us group them in the best category until voting begins.
Build an AI powered tool to help us categorize (2 weeks): There is a lot of information to parse. We experimented with vectorization of Giveth projects in a 40-dimensional space and were pleasantly surprised by the results. AI will be used to speed up the process, but the final results will require great human oversight.
Publish initial categorization draft (3 business days after the close of applications): Once the application deadline has closed, we will add the final applicants into our data set and work nonstop to publish a first draft of categorization, groupings and titles.
Rapid feedback and iterations (until the voting begins): We will work with the community to address feedback and concerns as they come up. It is important to set the category titles and the projects in each category before voting has begun, for the legitimacy of the process.

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:
Milestone 1: Specification Completion

Overview: Finalize the system design and architecture based on the provided designs and user stories.
Deliverable: Detailed system architecture and user interface design ready for public feedback.

Milestone 2: Core Features Development

Overview: Complete the development of core functionalities such as categorization of projects, integration with Pairwise, and list creation features.
Deliverable: A functional version of the application with core features ready for internal testing.

Milestone 3: Testing and Quality Assurance

Overview: Conduct comprehensive testing of all features and functionalities to ensure they operate as expected.
Deliverable: A report detailing the results of unit testing, integration testing, and user acceptance testing.

Milestone 4: Application Launch

Overview: Officially release the application to the public, enabling badgeholders to discover, view, and interact with Lists.
Deliverable: A live and fully functional application available for badgeholders.

Milestone 5: Continuous Feedback and Iteration

Overview: Actively solicit feedback from the community and make necessary refinements and enhancements based on their insights.
Deliverable: Monthly updates on the forums detailing improvements and adjustments made to the application based on community feedback.

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

Support we would appreciate, though not required:

Modifications to the project submission form that would help us categorize would save a lot of double work, even if these were optional.

We would love to add 2 questions, one open ended to get specific categorization data and one that simply asks “What other projects in the Optimism Ecosystem are similar to yours?”

Access to project contact information will help us reach out in case we need extra information to better categorize each project.

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)

Access to upfront capital is not a barrier for us. However, a small upfront cash grant would benefit immediate project expenses. We understand this is not guaranteed.

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.✔
I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant✔
I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual✔
I confirm that I have read and understand the grant policies✔
I understand that I will be expected to following the public grant reporting requirements outlined here✔

-- end of application --

Foundation Mission (RFP) Application (WIP)
Please verify that you meet the qualifications for submitting at the above Tier:
Opti.Domains is a grant recipient in season 3, Cycle 11
Grant Update: https://gov.optimism.io/t/ready-gf-phase-1-proposal-opti-domains-interoperable-domain-name-for-the-op-stack/5510/22?u=opti.domains
As clarified by @lavande: “That sounds like Fledging! Receiving and executing on a grant constitutes working with the Collective”
https://gov.optimism.io/t/collective-trust-tiers/5877/10?u=opti.domains
Alliance name: Opti.domains
Alliance Lead: Chomtana Chanjaraswichai (Opti.domains)
Contact info<EMAIL_ADDRESS>L2 recipient address: TBD
Please list the members of your Alliance and link to any previous work:
Chomtana Chanjaraswichai (Opti.Domains, Alliance Lead)

Optimism TechNERD
Solo developer developing Opti.Domains
1st in Axelar 2nd Code4rena audit contest
2nd in Axelar 1st Code4rena audit contest
Contribute to Seaport in Gas Optimization
Fork Wagmi Library to integrate support for custom ENS UniversalResolver support
Fork Rainbowkit Library to integrate support for the domain name on Optimism
Participated in SCB Bangkok Blockathon 2023 and won 3rd price with 838.Earth project
Participated in SCB Bangkok Blockathon 2021 and won 2nd price with Estate-Onblock project
Has experience developing Kaokonlakao, the largest running event in Thailand with more than 10,000 participants actively submitting their running progress to our system with a bunch of volunteer grading submitted progress.
Won silver medal in 13th Thailand Olympiad in Informatics (TOI13)
Won many hackathons in the past

Petch Luancharoen (UX/UI Designer, Inspex Point of Contact)

UX/UI Designer at Inspex
Former UX / UI Designer at DoDeep

What makes your Team best-suited to execute this Mission?

We have proposed Rubric-based list builder on the previous mission
We have intensive experience with grant council Rubric-based list scoring system
Chomtana, alliance lead is an Optimism TechNERD
Our team has developed Opti.domains, the first protocol utilizing EAS on the Optimism mainnet, as of the time of writing.
Opti.domains has implemented social verification system utilizing EAS.
We can advise the Optimism team on EAS schema and attestation design, ensuring optimal task accomplishment.
Our alliance is the first to inquire about the project requirements.
We have successfully completed most of the tasks associated with the "Specification for implementation, design approach, and architecture for the functionality listed above."
Our alliance leader has experience developing Kaokonlakao, the largest running event in Thailand with more than 10,000 participants actively submitting their running progress to our system with a bunch of volunteer grading submitted progress. So, we have proven that we can handle the load of the RetroPGF 3 project discovery and voting system.

Professional level EAS experience
We have attested more than 10,000 attestations in Optimism Goerli!
We have a long experience with EAS from the start. We have developed our Opti.domains smart contract and social verification backend integrated with EAS a few months ago and have developed a good relationship with EAS team in github discussion.

https://optimism-goerli.easscan.org/address/0xf01dd015bc442d872275a79b9cae84a6ff9b2a27

https://optimism-goerli-bedrock.easscan.org/

https://optimism-goerli-bedrock.easscan.org/address/0xf01Dd015Bc442d872275A79b9caE84A6ff9B2A27
We are the first ones who utilize EAS to attest social verification. It's quite complex but we have made it.

Try one yourself at https://town-testnet.opti.domains/
We have published the EAS SDK package for our internal migration process 3 days before the offical launch of EAS SDK.
Proof:

Our EAS SDK - 1 August - https://www.npmjs.com/package/@optidomains/eas-sdk
Official EAS SDK - 4 August - https://www.npmjs.com/package/@ethereum-attestation-service/eas-sdk

On 4 August, we have finished our migration process to have it compatible with latest EAS (Smart contract and social verification backend) in 3 days which is a very remarkable duration.
Not only EAS SDK but we can also deploy and customize the EAS indexer (https://github.com/ethereum-attestation-service/eas-indexing-service) ourselves. So, it won't be blocking if there are any problems in your EAS indexer because we can host it ourselves.
But in fact, we can use https://optimism.easscan.org/graphql public endpoint for basic attestation query
We also detect errors in the official optimism document regarding EAS and have opened a pull request
https://github.com/ethereum-optimism/community-hub/pull/853

This demonstrates our great understanding of EAS at a level that can advise you in the design of schema especially on social verification if you need it. Our intensive experience with EAS that significantly reduces development time and increase the quality of RetroPGF 3 List Creation UI development
Experience with grant
We have experience with grants and have simulated the RetroPGF voting process in the previous RetroPGF 2 and a new proposed one. It's clear that RetroPGF 2 voting experience is horrible as badgeholders are required to copy their ballot to deform.
The new process solves this redundancy, however, assigning op for each project is still hard due to the reason explained in the Extra feature: Rubric-based list builder section below.
Please describe your proposed solution based on the above Solution Criteria:
Live Prototype
(To be provided by 4 September)
Core functionalities
We will develop core functionalities as listed in the requirements
Wallet connect

Users can connect their wallet on the Optimism mainnet chain with Rainbowkit's industrial-grade wallet connect system.

Discover Projects while managing list

Users can explore all nominated project
Users can search for a specific project by text
Users can filter projects by categories
Users can sort projects by name and others
Users can view detailed information about a specific project including general information about the project (name, creator, profile picture, social media links, etc.) and specific information relevant to RetroPGF’s goal of aligning impact and profit (description of contributions, links to contributions, impact description, funding history, etc.).
Users can easily view social media linked to each project

List system

Only Badgeholders can create a maximum of 5 lists
Users can view all published lists
Users can view details of each list
Badgeholders can specify a list name
Badgeholders can specify description and impact evaluation description
Badgeholders can add projects to the list
Badgeholders can assign OP amount to each project
Badgeholders can fork a list
Badgeholders can update their list
Badgeholders can delete their list
Badgeholders have an easy user interface to view project information without switching to a new tab
Badgeholders can choose to share their list publicly or kept private as a draft (Draft mean not published)
Badgeholders can create a list by using Rubric-based scoring (Details below)
Shared list will have a link that can be shared to others
Voting time remaining is shown to the user
Project added and OP allocated progress bar is summarized
Should show which list is forked form
List should be attested to Ethereum Attestation Service (EAS)

Rubric-based list builder
Imagine a badgeholder who is faced with the challenging task of assigning the number of OP token to a project, this decision is influenced by multiple factors. The number of OP allocated to a project must consider various aspects, not only the impact of an individual project but also including the total number of projects and the relative earning of each project.
Assigning correctly in the first pass is nearly impossible, necessitating second, third, and subsequent passes to craft the perfect ballot.
In our opinion, we can utilize the grant council scoring system to assist badgeholders in independently scoring each project based on its impact, separate from other projects. Subsequently, we can employ these scores to calculate a perfect final list. However, it's essential to acknowledge that each badgeholder may possess their own impact evaluation metrics. Thus, we propose allowing badgeholders to design their individual metrics, while providing a base template for each category to ensure consistency.

A prototype is worth thousand of words, please take a look at our prototype (To be provided by 4 September)
Frontend
Framework
We propose employing Gatsby, an advanced, open-source framework that employs React and GraphQL. Gatsby excels at CMS development, aligning perfectly with the project discovery system's requirements. This proficiency is exemplified through an internal scraper that procures project information and images from EAS and IPFS, and subsequently caches it into numerous JSON metadata, images, and markdown files. This process is enabled by the non-overlapping nomination and voting periods in RetroPGF.

Among Gatsby's numerous advantages, the extensive plugin ecosystem is noteworthy. In this project, we aim to leverage gatsby-source-filesystem for reading cached markdown files, gatsby-transformer-remark for transforming these markdown files, and gatsby-plugin-sitemap for SEO-optimized sitemap creation.
Gatsby can also execute all operations required on our project and list discovery page. Gatsby's features are described comprehensively here. However, to fallback for non-cached list, we plan to utilize simple API fetching to fetch non-cached list upon request.

If real-time dynamic changes to the projects list are required, we will enable our scraper to push the updates to our frontend GitHub repository every time a new project is nominated. This action will trigger the build and deployment pipeline of our Cloudflare Page, ensuring that the latest changes are reflected and available to users within 5 minutes. We may try to use the client route as a fallback if one has entered that page before it was built. It will query our REST API and show the project detail instantly.
This approach facilitates a bifurcated development process for our frontend and EAS and IPFS-related scraper, with each section proceeding independently and in parallel. The frontend will be under the purview of our four developers with proven expertise in rapid, high-quality application development, while the scraper will be the responsibility of Chomtana, a solo developer from Opti.domains, known for pioneering EAS use in their projects and possessing extensive EAS experience.

Deployment
Gatsby compiles into a static site, thereby providing the flexibility to host it on any static site hosting service. We propose using Cloudflare Page, renowned for its 100% Uptime SLA and unlimited bandwidth.

With the Cloudflare Pro plan, we have the capacity to build 5000 times per month. In our design, we aim to build slightly more than the total number of lists created by badgeholder which shouldn't exceed 3000 lists.
(Gatsby cloud is 2 times more expensive and may possibly create unnecessary stack bonding which greatly affects maintainability in the future. Cloudflare offers unlimited bandwidth and unlimited pages while gatsby cloud doesn't and only support 5000 pages. Cloudflare offers global CDN while gatsby cloud is limited to US and EU.)
Database
We plan to leverage MongoDB (Or other document-based NoSQL database) along with comprehensive backup mechanisms, ensuring our data is hosted securely and has sufficient capacity for peak-hour demands.
Upon analysis, we found that the RetroPGF 3 listing favor a NoSQL document-based database as follows:
Lists along with owners, impact evaluations, and votes
(TODO)
[
  {
    "_id": "...",
    "walletAddress": "...",
    "signature": "...",
    "name": "...",
    "description": "...",
    "forkedFrom": "<List ID>",
    "list": [
      {
        "projectId": "...",
        "opAssigned": 72000,
        "comment": "",
        "evaluation": {

        }
      }
    ],
    "rubrics": [

    ]
  }
]

This strategy considerably reduces development time and cost by avoiding unnecessary complexity.
Backend
Our intent is to create a REST API using the Express.js (with TypeScript) framework. We will implement SIWE for Ethereum wallet sign-ins, Passport for social logins (if necessary), and Mongoose for MongoDB database communication. While GET endpoints will be publicly accessible, submission endpoints will be safeguarded through cookie-based UI restriction for security reasons. Having successfully integrated these elements in our Opti.domains project, we can assert the feasibility of swift development.
Listing API
Listing API endpoints include List listing, Classical list creation (Draft, Edit, Publish), Rubric-based list creation (Draft, Edit, Publish) and List forking.
Project scraper
Project scraper will run only one time to projects from either Agora or Supermodular RetroPGF voting platform. Project data will be cached in the frontend and no API query is needed anymore.
List scraper
EAS and IPFS scraper constantly poll list attestation from EAS and from our backend and then fetch data from IPFS. This data is saved to two places: MongoDB and cached to Gatsby content. MongoDB is used to serve uncached content while Gatsby pages built with Cloudflare page will serve cached content.

Deployment
For backend API deployment, we propose utilizing AWS Lambda, an AWS serverless solution that we don't need to worry about scaling tasks at all.
Our EAS and  scraper will be deployed to Opti.domains server because we require regular updates to our Git repositories. To ensure safety in case of any emergency situation, the EC2 image will be snapshotted. The scraper will be executed by a cron job event that runs every minute, ensuring timely and automated data collection.

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work:
We champion the agile methodology in product development due to the potential uncertainty of initial requirements. Feedback from project sponsor @JSeiferth, the Optimism team, and Badgeholders is instrumental in refining these requirements, thus aligning our product to optimally meet user needs.
We will deploy our live development endpoints from the project start and open source our repositories
Project Implementation Specification, Design Approach, and Architecture
We will complete this before grant is accepted. However, with agile methodology, it has enough flexibility to change between sprints.
Sprint 1: Frontend Hackathon
Development: 28 August - 17 September 2023
Review: 18 - 20 September 2023
In this phase, our team will develop the frontend using mock-up data. This approach ensures no backend or scraper feature interactions are required at this stage.
Sprint 2: Backend & EAS Integration
Development: 21 September - 8 October 2023
Review: 9 - 11 October 2023
The second sprint will be dedicated to the development of backend API, database, and integration of the backend systems with the already developed frontend.
Sprint 3: Testing, Bug Fixes and Additional Features
9 - 14 October 2023
Utilizing the feedback provided by the Optimism team, we will seek to improve our product through rigorous testing and bug fixing.
This is done in parallel with the backend & EAS integration review and production deployment sprint.
Sprint 4: Production Deployment
12 - 14 October 2023
Deploy RetroPGF List Creation UI to production
Maintenance and Support
After production deployment, we will provide maintenance and support. As I am a TechNerd, badgeholders and users having problem with our tool can open a user or dev support ticket on the official Optimism discord to discuss the problem with me seamlessly.
Since our deployment is mostly serverless, each cloud provider will also provide 24/7 maintenance support for our RetroPGF list creation UI.
Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

Get feedback from the Optimism Foundation team on the agile Review phase
Everything will be open source in an isolated GitHub organization for this project
Successfully deploy to production on 14 October 2023
Successfully integrate with voting UI from both Agora and Supermodular team

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

We need to keep in touch with the Optimism team especially @JSeiferth, the project sponsor in our agile review phase.
It would be great if we can get feedback from badgeholders especially on our agile review phase.
We would like @JSeiferth to connect us to Agora and Supermodular team.
Since you have limited list creation ability to badgeholders, we need to have our alliance leader, Chomtana become a badgeholder to be able to provide sufficient support in the production.

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant:
Upfront Capital is not a barrier. However, with a much lower grant size, getting some small upfront cash grant would be great!
Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

[x] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
[x] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
[x] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual
[x] I confirm that I have read and understand the grant policies
[x] I understand that I will be expected to following the public grant reporting requirements outlined here

-- end of application --

Foundation Mission (RFP) Application

Alliance Lead: Luizakp @luizakp
Contact info<EMAIL_ADDRESS>| luizakp#4139 (Discord)
L2 recipient address: oeth:0xa41214012d4462ecBB0724673897Ee0dCc0fDF49
Please list the members of your Alliance and link to any previous work:

Team work: https://github.com/bleu-studio
Previous work:

Vault Internal Balances Manager: an application to manage tokens within Balancer Vault's Internal Balance. This tool assisted users affected by the Euler hack in recovering their funds once Euler eTokens were frozen;
Pool Simulator: a dashboard designed to simulate Balancer pools behavior. It aids the Balancer DAO in determining parameters that improve the performance of the pools;
Pool Metadata: this tool streamlines the on-chain management of Balancer’s pool metadata via IPFS. It allows pool owners to store and display custom metadata on a UI, enhancing user understanding without requiring Balancer's direct oversight;
Contributions to Balancer's subgraphs, and several other packages.

What makes your Alliance best-suited to execute this Mission?

This mission, tailored for the Ember Alliance, represents an ideal platform for us to not only build a solid collaboration with Optimism but also to be pivotal in reinforcing its decentralized foundation. Being an Ember Alliance, our team is poised to use our technical expertise and is eager to tackle fresh challenges within OP.
As highlighted in our "previous projects", we pioneered several applications for Balancer, enabling only the Pool Owner to save custom Pool Metadata on-chain via IPFS. Having primarily focused on the web3 frontend in our past projects, we are well-acquainted with the tech stack required for this mission;
Balancer and Optimism share a strong and collaborative relationship, and our aspiration is to be close to their partners. We share Balancer's alignment with Optimism;
We're committed to delivering. To dispel any doubts that we'd be able to deliver this RFP we put together a PoC for this RFP here: https://www.loom.com/share/e9d56af1b5564b9292730bdee4a278f5?sid=5b066757-4504-4edc-9e13-7ddd490d6792.

Please describe your proposed solution based on the above Solution Criteria (if applicable):
For this RFP, we've outlined the following steps:

Establishing wallet connectivity to the chain (e.g. through wagmi/rainbowkit);
Extracting and showcasing RetroPGF Round 3’s Projects data

Retrieving application details (like names, photos, and linked lists) from EAS

Design a user-friendly interface for list creation

Input fields will include: Name, Description, Impact Evaluation Description, and an Impact Evaluation link, and have validations;
Selected projects will feature their names and respective OP allocations;

Add validations to ensure a project does not receive more than 10M OP and the cumulative allocation doesn’t exceed 30M OP;

Save form data to IPFS, then persist it to EAS;

Ensure creation is only available to badgeholders;

On-chain verification will be employed;

Badgeholders will have the privilege to craft up to 5 lists

Show lists data extracting EAS data via its attestation UID, fetching the IPFS hash, and retrieving metadata;

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work:
Assuming a start date of September 15th, 2023.

Milestone
Delivery Date

Specification
September 15, 2023

Set up project & deployment
September 15, 2023

Create List feature
September 29, 2023

View List UI
October 6, 2023

Testing & QA
October 13, 2023

Monitoring and support
Until March 2024

We will commit to improving, supporting, and featuring improvements for subsequent RetroPGFs until March 2024.
Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

Create a public repository and deployment;
Have the UI design established;
Deploy feature: Badgeholders are able to create Lists;
Deploy feature: Anyone is able to view created Lists;

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

Regular feedback and collaboration with @JSeiferth and the broader Optimism team

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)

Given the size and operational costs associated with our team, an upfront cash grant would ensure that we can maintain our operational efficiency. This support would significantly aid our contribution to the ecosystem

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

[x] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
[x] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
[x] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual
[x] I confirm that I have read and understand the grant policies
[x] I understand that I will be expected to following the public grant reporting requirements outlined here

-- end of application --

Hi @JSeiferth, We have developed a live prototype demo which accounted for about 40% completion of RetroPGF 3 list creation. Our prototype currently supports 2 list-creation methods:

Classical: Assign OP amount to each project manually.
Rubric-based: Score each project based on a rubric. OP amount is assigned automatically based on the final score.

Demo Link
Our prototype is live at: https://retrolist.opti.domains
Demo Video
https://youtu.be/AYjrHolE_s0
Screenshots
Note: Not an actual UI design. This is a working prototype that demonstrates the functionalities
Classical List Creation

Rubric-based List Creation

Submissions for this RFP are now closed. Thanks to everyone who submitted a proposal!
Someone from the Optimism Foundation will reach out on or shortly after Aug 11 to communicate which proposal(s) have been accepted and schedule a kickoff.
In the meantime, feel free to tag me here or reach out directly<EMAIL_ADDRESS>with any questions 🌞

Hi all – thanks for the excellent submissions! 🌞
The Optimism Foundation has selected Supermodular’s proposals to move forward with the work described in this RFP. That said, we're really excited about the amount of interest from everyone here!
To all the other teams that applied, we'd love to help you find the right way to contribute to the Optimism Collective!
There will be more RFP's & Ecosystem Project Ideas in the Ecosystem's Contribution repo and future opportunities to contribute to RetroPGF.
If you have an idea of what you’d like to build for RetroPGF, feel free to reach out to me and/or post about it in the forum
Thank you again for your proposals!

RetroPGF is now live and we're happy to share what we've built here.
You can play around with the UI but you need to be a badgeholder to publish the list.
https://round3.optimism.io/lists/create
If you're curious about the code, you can find it here:
https://github.com/supermodularxyz/OP-RetroPGF

This is still listed as "open" but is in the "done" bucket. Can we close?
@JSeiferth


Messaging: Surveys upsell email campaign

Messaging
Context
We previously did a session replay upsell campaign. 3 emails, over 10 days.
We learned that a particular, personal style works best and bought around 20 new users into trying session replay for the first time. Now, I want to do a second test targeting getting users to sign up to a survey.
Targeting this because it's a feature which isn't widely adopted or publicised yet, would have wide relevance and isn't massively technical for non-engineer users. Creating a survey will also require users to opt-in to the early access, which I think is a very important thing to make visible to them. Users who see this screen will be more likely to join other betas.
Goal
Get users to create their first survey within two weeks of receiving an email.
Format
Email, customer.io. Broadcast x3.
Audience / Targeting
As before, I'll target paying users who have no previously created a survey and who have logged in at least once in the last 30 days (e.g. active users).
The cohort is around 1303 people.
Resources, timeline, responsibilities
@joethreepwood leading. It'll run as three broadcasts, over a period of 10-14 days to a targeted group.
Requested input
Any feedback welcome.
Previews
Drafts https://docs.google.com/document/d/1VbWAVQioxmTXahtURISSY5IDwO3XYsXMN0hLrYuS9pk/edit?usp=sharing

@joethreepwood Surveys is available for everyone (in beta) now, so no need anymore for early access.

You just had to throw a spanner into the works 😂
I may keep this focused on Surveys anyway, as the other EA items are either a bit less actionable or more complex atm, so I'm not sure an email campaign at this point is the right approach.

OK, I'm going to keep this focused on surveys and I'm going to run two variations. Both will be simple, short, personally styled and directly from me. But one will have gifs to give a visual element.
@annikaschmid / @andyvan-ph would love to get your quick eyes on the copy, please!
https://docs.google.com/document/d/1VbWAVQioxmTXahtURISSY5IDwO3XYsXMN0hLrYuS9pk/edit?usp=sharing

There's been no feedback on these, so I've set up the broadcasts as per the drafts and am planning to launch them next week.

We have two survey related tutorials now if you want to use either of them:

https://posthog.com/tutorials/feedback-interviews-site-apps
https://posthog.com/tutorials/survey

Otherwise looks good

This is now live and scheduled to send over the next 10 days, with a few days between each message..

@liyiy are surveys ready for this? i'm not quite sure how we feel about quality at moment...

@liyiy are surveys ready for this? i'm not quite sure how we feel about quality at moment...

My assumption was that this was more of a beta test upsell but if not then yes I think waiting maybe for another two weeks or so while I get in some more features should help for a more impressive general release upsell

So, we ran this upsell but ran into two main hiccups. The first is that, due to confusion with configuring the emails as multiple broadcasts, the first email in the sequence wasn't sent. The second is that we had 77 of the emails fail to deliver.
The first issue is my fault. The second is just bad data, nothing to be done about it.
Despite this, we had a good response. Overall stats:
Open rate: 52% (varies less than 1% depending on email)
CTR: 5-8% (depending on email)
Unsubscribes: 0.1% (1 user)
Conversion rate for making a survey: 0.6% (6 users)
Most crucially, we got actual user feedback!

One user reached out to me directly to express interest in NPS surveys (tutorial incoming: https://github.com/PostHog/posthog.com/pull/650 )
One user reached out to Li to give feedback on surveys
One user reached out to ask why behavioural cohorts can't be used
One user reached out to comment on the emails themselves and ask to be unsubscribed

The test revealed that the variants without a gif performed slightly (1 conversion) better than those with a gif, and had a higher click through rate too.
All in all, seems to validate doing targeted emails like this for new features and keeping to a format (as with the previous test) which is direct, personal and doesn't use gifs or images.


fix(hide): improved hide logic #63 65

Alaska Airlines Pull Request
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Fixes: #63 #65
Summary:
Logic for when to hide the bib moved from dropdown to datepicker and improved to handle when calendar buttons become disabled.
Type of change:
Please delete options that are not relevant.

[x] New capability
[ ] Revision of an existing capability
[ ] Infrastructure change (automation, etc.)
[ ] Other (please elaborate)

Checklist:

[x] My update follows the CONTRIBUTING guidelines of this project
[x] I have performed a self-review of my own update

By submitting this Pull Request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Pull Requests will be evaluated by their quality of update and whether it is consistent with the goals and values of this project. Any submission is to be considered a conversation between the submitter and the maintainers of this project and may require changes to your submission.
Thank you for your submission!
-- Auro Design System Team

This PR will not pass the testing threshold until this auro-dropdown PR is released.

:tada: This PR is included in version 1.2.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Refactor: API key storage to use SecretStorage and improve UX

@amitassaraf
This pull request implements the changes I proposed in Issue #12 to modify the API key storage method to use Secret Storage.
Changes Summary

API Key Management

Introduced an apiKeyManager class to handle API key management using Secret Storage.
Modified existing API key registration and retrieval processes to use the new apiKeyManager.

Enhanced Security

Added type="password" to the API key input field in the UI to mask the key and improve confidentiality.

New API Key Setting Method

Implemented a command palette option to set the API key (ExtensionTotal.setApiKey).
Note: With this addition, we may consider removing the WelcomeViewProvider. This is open for discussion.

Documentation Update

Updated the README.md with revised API key registration instructions.

UX Improvements

Current behavior

The scan process continues to execute API requests even with an invalid API key, resulting in unnecessary network traffic and delayed user feedback.

Improved behavior

Modified the scan process to abort immediately upon detecting an invalid API key. This change prevents unnecessary API requests, improves efficiency, and provides immediate feedback to the user about the API key status.

Additional Considerations

User Notification

Due to the change in API key storage method, we may need to notify users through release notes or other communication channels.

Testing and Review Request
I kindly request your review and feedback on these changes, particularly focusing on

The implementation of Secret Storage for API key management.
The UX improvements in handling invalid API keys.
The potential removal of the WelcomeViewProvider.

Please note that I have conducted basic functionality testing on my end.
Fixes #12

Hi @K-dash Thank you for your contribution! I merged it now and it will be shipped in our next release.


Small cleanups.

Don't hardcode PCLK frequencies.
Remove unused #includes.
Enable USB2 console only when the peripheral exist.

Looks good for me too that cleanup the code to be more generic