[bug] nodes.json contains invalid/old data

Version
Checklist:

[x] I am not using Home Assistant. Or: a developer has told me to come here.
[x] I have checked the troubleshooting section and my problem is not described there.
[x] I have read the changelog and my problem is not mentioned there.

Build/Run method

[ ] Docker
[ ] PKG
[x] Snap package
[ ] Manually built (git clone - yarn install - yarn run build )

zwavejs2mqtt: 6.2.0.fa6b2ab
zwave-js: 8.9.3-0-pr-4011-940427a
home id:<PHONE_NUMBER>
home hex: 0xdbaaadc0
Describe the bug
nodes.json contain nodes that is removed from the network. Shouldn't cause big issues, but I guess when the controller reaches #232 it will start re-use node id's, then causing new nodes using old nodes.json data.
Expected behavior
nodes.json to be in sync with the nodes in the network.

nodes.json contain nodes that is removed from the network. Shouldn't cause big issues, but I guess when the controller reaches #232 it will start re-use node id's, then causing new nodes using old nodes.json data.

I know that, I did it on purpose as nodes.json could be also restored from an old network. Let's say you want to add all nodes back to a new controller and you have a nodes.json backup you can add a node and you will get it automatically named as it is added

But that will require you to re-include them in the same order, and be lucky to not fail the inclusion so they actually get the same id?
If you restore, then you probably have a backup of the nodes.json file too?

I mean it doesn't create any issue to me, when I needed to restore a network I simply re-added all nodes one by one in the same order (and If I did it worng I just renamed them) but if this is causing issues I can just keep it in sync with the actual network

But I guess you have a quite small network. In my case I'm already on node id 182. That's simply because a Smart Start device failed to include for long, so around 40 ids was used without me doing anything, just for that node.
I've never been able to re-build the network exactly the same. I have at the time 56 nodes, but around 20 nodes are still missing. I would expect to hit the limit of 232 nodes when I'm going to include them since inclusion of 56 nodes have gotten me to node 182 already. 🤪
Do you have a context, that could prevent auto-removal, when the context is in "replace failed node"?
But this doesn't make a huge problem though, except confusion when a new node is identified as something unexpected. Especially in large networks.
One possible solution could be to ask the user to re-use the data in nodes.json after including a device - if there is data for that node id in nodes.json?

I would expect to hit the limit of 232 nodes when I'm going to include them since inclusion of 56 nodes have gotten me to node 182 already. 🤪

I think that once reached the id limit controller will start to use the free ids :)
BTW I should add a check in replace failed call that sets a var that could prevent the remove to drop nodes.json data

But that's my point; there's IDs with data in the nodes that I consider "free", that the controller will pick when I hit the limit and it will start picking unused IDs in-between (I assume) old nodes.


Incorrect display of podcasts in Discord RPC

Describe the bug
When you listen to a podcast, the Discord profile says "loading".
To Reproduce
Steps to reproduce the behavior:

Enable the podcast.
Look at the Discord profile.

Expected behavior
Make some kind of unique display for podcasts, or make them not visible in Discord RPC.
Screenshots/Video

Client info (please complete the following information):

OS: Windows 10 (Build 22H2)
Modification version: 1.8.4
Yandex Music version: 5.8.3

Thanks for your bug report. I can reproduce this. Will be fixed in next release

Fixed in 1.9.0


ShEx for Module "Care Pathway" and "Disease History and Diagnosis"

Dear all,
I create ShEx for the modules "care pathway" and "disease history and diagnosis", which comply with the diagrams (https://github.com/ejp-rd-vp/CDE-semantic-model/wiki/Care-pathway-SIO and https://github.com/ejp-rd-vp/CDE-semantic-model/blob/develop/images/5_Disease_history_and_diagnosis_SIO.png).
Thank @markwilkinson for your "example turtle". I validate it against the ShEx, which turns out some conflicts:

What
ShEx (Diagram)
Turtle
How is it in Core Model

Type of Person Node
sio:person
sio:patient
sio:person is used

Type of Patient Role Node
sio:patient-role
sio:patient-role, sio:role
only sio:patient-role is used

Relationship between bithDateQualityShape and its output
sio:has-measurement-value
sio:has-measurement-value
In diagrams of other modules, sio:is-base-for is used

Type of birthDateOutputShape
sio:realizable-entity
sio:measurement_value
In diagrams of other modules, sio:realizable-entity is used

Medical Diagnosis
as a mandatory node connecting to role and its output
Missing
Such inconsistency leads to "missing-property rrrors" from Role instances

Look forward to suggestions and reviews.

@sxzhang1201 I have updated both care pathway and disease modules. My PR is still under review. If my changes are accepted then you have to change ur shex too. I will give you heads up when my PR is merged. Can you update this PR after that please?

@sxzhang1201 I have updated both care pathway and disease modules. My PR is still under review. If my changes are accepted then you have to change ur shex too. I will give you heads up when my PR is merged. Can you update this PR after that please?

Sure, I will review yours first 👍


update deployment phase

added info on what needs to be ran during the deployment phase

@rtibi : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off


SignalRClient.SignalRError.webError(statusCode: 500)) About the occurrence of an error.......

Condition ; Same url address.
There is a difference between running HubSamplePhone provided by GitHub and when I import it to my project with Swiift Packages Manager or Pod.
When I include a library in my project I get a 500 error.
So I tested with Swiift Packages Manager or Pod with the source and not including the library.
No problem.
So, what do I need to do when I include it as Swiift Packages Manager or Pod?
Any answers would be appreciated.
thank.

Both should work the same. 500 error is an error from the server which typically results from an unhandled exception. Find what this exception is and this should give you a hint about what's going on.

Closing as I don't think there is anything that needs to be done on the client. Feel free to re-open with a repro if you determine it is a client issue.


Feature decision table

This PR contains decision table feature.

got this error while executing credit card application from develop branch
Failed to create engine: error creating shared action instances - failed to marshall RuleSessionDescriptor : json: error calling MarshalJSON for type *config.RuleDescriptor: invalid character ']' looking for beginning of value

Since it is in develop branch need to mention that in flogo.json imports.
"imports": [
    "github.com/project-flogo/contrib/trigger/rest",
    "github.com/project-flogo/contrib/activity/log",
    "nil<EMAIL_ADDRESS>    "nil<EMAIL_ADDRESS>    "github.com/project-flogo/contrib/function/string"
  ]

Create flogo app with below command.
flogo create -f flogo.json --cv v0.9.3

Follow other steps as is from readme.

Thanks.


Add two scenarios for pool resizing issue.

Pull request guidance
Thank you for submitting your contribution to our support content! Our team works closely with subject matter experts in CSS and PMs in the product group to review all content requests to ensure technical accuracy and the best customer experience. This process can sometimes take one or more days, so we greatly appreciate your patience.
We also need your help in order to process your request as soon as possible:

We won't act on your pull request (PR) until you type "#sign-off" in a new comment in your pull request (PR) to indicate that your changes are complete.

After you sign off in your PR, the article will be tech reviewed by the PM or SME if it has more than minor changes. Once the article is approved, it will undergo a final editing pass before being merged.

#sign-off

The private PR https://github.com/MicrosoftDocs/SupportArticles-docs-pr/pull/5731 is merged, so I closed this PR.


Note always deleted when "Delete after reading"

Describe the bug
Create a note with "Delete after reading" checked. If user open the note with incorrect password. The note will be deleted.
What happened?
The note should not be deleted if user entered an incorrect password.
System information
Chrome 130.0.6723.70
Where did you encounter the bug?
Public app (enclosed.cc)

Hi @adoyle-h
That's a good point, not easy to fix though regarding the current architecture. Note that the user can try other passwords as long as they do no refresh or close the page.
Currently, the encrypted note payload is required to check if the password is correct or not.
But the server delete the note after the first read of the payload, so the payload is not available anymore.
Here is the flow

User A create a note with Delete after reading and a password
User B open the note
a. The client see the note is Deleted after reading from the url metadata
b. The client ask server if the note exist (that the note is not already deleted)
c. The client warn the user that the note will be deleted after reading
d. The client fetch the note payload from the server + the server delete the note
e. The client prompt the user for the password and try to decrypt the note

The lock here is that the payload is needed to check the password, but the payload is deleted after the first read.
Some options:

Option 1 : could be to store the payload in the client side storage (localStorage or sessionStorage) and delete it after the first read. But it's not secure at all, prone to XSS attacks and require strong expiration policy.
Option 2 : don't delete the note after the first read, but after the first decryption. The client will have to tell the server that the note is decrypted and must be deleted. But it's not secure at all since one could make a script or 3rd party client that no longer tell the server that the note is decrypted and can be deleted.
Option 3 : warn the user on password prompt to not refresh the page or close the tab. But it's not really user friendly.

I'm not sure what to think about this, I'll think about it to see if there is a better solution.
Thus I'm open to any suggestions or ideas on how to handle this.

Hello,
It seems the quick fix is Option 2. Another way is to create another endpoint to receive payload only after password validation. So: client checks if the password is set -> client asks for the password (if set) -> client sends the password to the server for validation -> client requests payload and decrypts the content with the same password (if valid).

Hi @ilyakonovalenko
Thanks for the suggestion!
Option 2 is a straightforward fix, but as mentioned, it's inherently less secure because it relies on the client reporting the decryption success. This introduces the risk of someone bypassing the deletion trigger, leading to unintended persistence of sensitive data
Regarding the proposed endpoint to validate the password server-side, this approach unfortunately compromises the zero-knowledge architecture we’re aiming for. In our setup, the server should never see or process the password, as that would undermine the end-to-end encryption guarantee. The password needs to stay on the client side

Then it seems there are only two ways for now:

Implement option 2 as it is with note author notification, so that author is aware of possible security issues.
Disable an ability to delete after reading in case some password is set. Non user-friendly, but would make the system most secured for now.


Running a Windows Chrome binary from WSL not working

Node Version: 9.8
Protractor Version: 5.1
Angular Version: N/A
Browser(s): Chrome 65
Operating System and Version Windows 10 Enterprise
Your protractor configuration file

Currently, the following config can be added in order to make WSL (Windows Susbsystem for Linux) use the locally installed Chrome on Windows in order to run component tests:
  capabilities: {
    browserName: 'chrome',
    version: '',
    platform: 'ANY',
    specs: [path.join(process.cwd(), 'features', '**', '*.feature')],
    chromeOptions: {
      binary: "/mnt/c/Program\ Files\ \(x86\)/Google/Chrome/Application/chrome.exe",
      args: ['--no-sandbox', 'lang=en-US', '--disable-gpu', '--always-authorize-plugins',
        'user-data-dir=node_modules/.cache/chrome/',
        'disk-cache-dir=node_modules/.cache/chrome/',
        'load-extensions=node_modules/.cache/chrome/',
      ],
    },
    loggingPrefs: {
      driver: process.env.LOG_LEVEL_DRIVER,
      server: process.env.LOG_LEVEL_SERVER,
      browser: process.env.LOG_LEVEL_BROWSER,
      performance: 'ALL',
    },
  },

However, this just results in Chrome simply launching, but not navigating to the actual system under tests.

@rfgamaral has been able to get this working by explicitly using the Windows versions of Selenium and WebDriver: https://github.com/Microsoft/vscode/issues/49908#issuecomment-390613742

@rfgamaral has been able to get this working by explicitly using the Windows versions of Selenium and WebDriver: microsoft/vscode#49908 (comment)

If I got this right, Chrome runs on Windows so you need to use Windows paths and protractor runs through WSL so you need WSL paths for the protractor configuration. And since Chrome runs on Windows it also needs Selenium Windows binaries. That's the Gist of it.

Think so! Trying to get this working myself :-)


Fix id reading method

Create an automaton to verify illegal id composition: beginning with number followed by letters.

This kinda of error will be verified in syntactic analyses


Foundation Mission Request: Retro Funding 4 Voting UI

Foundation Mission Request: Retro Funding 4 Voting UI

Proposed Foundation Mission (RFP): Retro Funding 4 Voting Client
S5 Intent: Governance Accessibility
Proposal Tier: Fledgling Tier
Baseline grant amount: 75k OP
Should this Foundation Mission be fulfilled by one or multiple teams: one
OP Labs or Optimism Foundation Sponsor: Jonas (gh: @JSeiferth, TG/Discord: @jonassft)
Last Submission by: April 12th
Selection by: April 17th
Completion date: 31st October 2024

How will this Foundation Mission (RFP) help accomplish the above Intent?
Retroactive Public Goods Funding (Retro Funding) Round 4 is taking place from May til August and will reward Onchain Builders who contribute to the success of Optimism. This round seeks to expand the reach and impact of the network by rewarding those building across the Superchain, increasing demand for blockspace, and driving value to the Collective. This includes builders who bring new users to the Superchain, drive network effects and protocol usage.
Retro Funding 4 experiments with impact metric based voting, in which voters express their preferences by selecting and weighting a number of metrics, instead of reviewing or voting on individual projects. Thus the voting experience looks vastly different to any existing grant or public goods voting experience.
Please refer to the impact calculator (spec), built by Buidl Guidl, as an early stage prototype of a metric-based voting experience.

Within the voting client, badgeholders (voters in Retro Funding) need to be able to discover relevant impact metrics, assign weight to them and submit their ballot. An excellent voting experience is core to supporting the work of badgeholders and ensuring an accurate Retro Funding process.
What is required to execute this Foundation Mission (RFP)?
Completing this mission requires building a frontend that powers the voting experience of badgeholders in Retro Funding 4. The Frontend will be based on existing designs and requirements, that will be provided to the team(s) that take on this mission.
Core functionality of the voting client:

Onboarding: When a badgeholder lands on the voting application, they are greeted with a small onboarding flow, surfacing relevant information and linking to important resources
Discover impact metrics: A badgeholder is able to discover impact metrics. Within a list of metrics a badgeholder can see metric name, metric creator, metric description, metric application among projects, as well as the option to add the metric to their ballot.
 The badgeholder is able to add new impact metrics to their ballot and edit the weighting of impact metrics. Within the ballot view, a graph visualization of the applied impact metrics is surfaced to the badgeholder, so that they can understand how their decisions impact the allocation of OP among projects.
Submit ballot: A badgeholder is able to submit their ballot
Testing mode: non-badgeholders can access the same functionality in a testing enviorement

Technical implementation:

Leverage Agora’s API for voting functionality, including reading project metadata, updating ballot state and submitting ballots
Leverage Open Source Observer’s API for impact metrics

The rollout of functionality of the application will be done in multiple phases:

Phase 1: Prototype & user testing (May 31st 2024): core functionality is available and at least 5 user interviews with badgeholders have been made.
Phase 2: Voting (June 24th - July 8th 2024): badgeholders are using the voting client to vote.
Phase 3: Results (July 15th - October 2024): The voting client displays results of Retro Funding 4

What milestones will help the Collective track progress towards completion of this Foundation Mission (RFP)?

Specification for implementation, design approach, and architecture for the functionality listed above.
Open-source code repository to observe progress over time, as well as weekly progress updates.
Launching Phase 1: Prototype & User testing
Launching Phase 2: Voting
Launching Phase 3: Results

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

Qualitative feedback on the voting experience of Retro Funding Round 4, collected via survey.
Number of badgeholders who successfully voted via the frontend

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 below. Submissions will be open until April 12th, at which time the Foundation will review all submissions and select one teams 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 --

Foundation Mission (RFP) Application
Please verify that you meet the qualifications for submitting at the above Tier: Verified
Alliance Lead: KC
Contact info<EMAIL_ADDRESS>L2 recipient address: 0x365659242D26c4BE14378056f2D55EbC0F7C90ee
Please list the members of your Alliance and link to any previous work:

KC: Product/Tech
Chris: Product/Tech
Jakob: Operations
2 FE web developers on our team
1 UI Designer

Links to previous work:

[DAO builder] (https://app.networkstate.social/wizard/community)
[DAO management] (https://app.networkstate.social/dao/base/0x1f7b43242860d1dfeb3872cabcb3ae86c440817c):
ERC 20 Events ticketing on Optimism, Base and Ethereum
Edge City dapp
Budx Dapp
SVG Passport Stack
Lemonade Hardhat environment- all smart contracts for the Superchain and other EVMs

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

We're passionate about governance
We're extending our DAO tooling to be able to run its own RPGF and QF rounds anyway; working with the collective to enable us to not build in Silos and build for people who will use it out the gate
We're horrible with marketing; and not sure who else will truly care to help us test and use this out the gate

Please describe your proposed solution based on the above Solution Criteria (if applicable):
We can build as per the scope
Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work:

April 20th: Deliver Figma prototype
April 30th: Deliver Figma prototype with iterated feedback
May 21st: Deliver Beta
May 28th: Deliver MVP with Badgeholder feedback incorporated
June 10th: Deliver ready product ready for voting
June 21st: Deliver ready product for results

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

Figma prototype approved by the community
MVP with Agora’s API for voting functionality, including reading project metadata, updating ballot state and submitting ballots
Ready product that leverages Open Source Observer’s API for impact metrics

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

Beta testers for Figma prototype feedback
Someone who can guide us on all the impact impact metrics

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.)
No problem with the lockup- we're building this anyway; having the opportunity to build together rather than a silo will be better for us.
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

Foundation Mission (RFP) Application
Please verify that you meet the qualifications for submitting at the above Tier: ✅
Alliance Lead: Elliott Alexander - BuidlGuidl
Contact info<EMAIL_ADDRESS>escottalexander on Telegram, X and Farcaster
L2 recipient address: 0x00080706a7D99CBC163D52dcF435205B1aD940D1 (safe.buidlguidl.eth)
Please list the members of your Alliance and link to any previous work:
The BuidlGuidl is a curated group of Ethereum builders creating products, prototypes, and tutorials to enrich the web3 ecosystem.
For this project the team will consist of the following:

Austin Griffith - Overseer
Elliott Alexander - Project Team Lead
Sam Wellander - Full Stack Developer
0xChijoke - Full Stack Developer
KC Pele - Full Stack Developer
Fran Pastor - UI/UX-Focused Developer
Elena Ultrav - UI/UX Designer
Other roles may be filled as needed

Here is some of our past work:

Impact Calculator Prototype
SpeedRunEthereum.com
PunkWallet.io
ABI Ninja
Hacked Wallet Recovery
Address.Vision

What makes your Alliance best-suited to execute this Mission?
Having built the above referenced prototype, the BuidlGuidl is eager to bring the project to completion. We have allocated resources internally and are prepared to work with the Collective and badgeholders to create a voting experience that exceeds all expectations. The BuidlGuidl's context is great, having been a recipient in past rounds in addition to our founder, Austin Griffith, being a badgeholder - we have a well rounded viewpoint on the challenges that lie in the voting process and see this values-based strategic overview approach as a huge step forward.
Please describe your proposed solution based on the above Solution Criteria (if applicable):

Onboarding flow: Bring badgeholders (or ballot reviewers) up to speed on the features available and the typical workflow for creating a ballot inside the application with an introductory modal. Helpful tooltips throughout the application will ensure maximum understanding of each feature.
Impact Metric Discovery: All available metrics will be listed with detailed descriptions accessible upon click.
Ballot viewing & editing: Impact metrics can be weighted differently as each badgeholder sees fit. Advanced filter criteria can be applied with an intuitive UI. These filters will allow badgeholders to include, exclude or add a reward multiplier effect based on any data point available on the applicants. All of a badgeholders impact metric selections along with their filters will be saved and made available to be used and further customized by other badgeholders for their ballot creation process. Comprehensive search functionality will make these easily accessible to each badgeholder.
Ballot submission: When a badgeholder is ready to submit they will be prompted to share their ballot on Farcaster (and other socials) so that they can show the community how they allocated funds to projects making the biggest impact. Social messages will contain links to the badgeholders ballot in a read-only mode.
Community Ballot Review: During and after the ballot submission period, badgeholders and non-badgeholders will have the ability to search through all submitted ballots and review their impact metrics, weightings and filters.

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work:
These two tracks are running in parallel:

Design finalization:

Graph, Impact Metric selections view (done)
Filters (in progress - April 16th)
User onboarding modal and tooltip placement (April 20th)
Final iteration after feedback (April 30th)

Primary functionality:

Graph, Impact Metric selections, Integration with Open Source Observer (done)
Saving user lists, Search functionality, ballot review views (April 20th)
Filters MVP (May 7th)
MVP ready for badgeholder review (May 14th)
Integrate actual project data through Open Source Observer and Agora (after application submissions are closed)
Address feedback and continued iteration (until voting begins June 24th)

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

Open Source repository with links to applicable designs updated frequently to show progress
Application is ready for badgeholder use in Retro PGF Round 4 for the purposes of voting
Non-badgeholders can use the application to review badgeholder ballots

Please list any additional support your team would require to execute this mission (financial, technical, etc.):
Jonas has been great to work with through the process of building the prototype. An open line of communication to someone in the Collective would be essential for us make sure we can overcome any obstacles that show up and also maintain expectations through the process.
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.)
Thanks to past Retro PGF rounds we do not require any up front capital to be able to take on this project.
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

gm Yitong from Agora here – if you're considering applying for this RFP and have questions about the Agora API, shoot me a DM on twitter or tg @zhayitong. happy to share the beta spec with you!

Foundation Mission (RFP) Application
Please verify that you meet the qualifications for submitting at the above Tier: ✅
Alliance Lead:
Kevin Owocki
Contact info:
<EMAIL_ADDRESS>| Owocki#1337
L2 recipient address:
0x00De4B13153673BCAE2616b67bf822500d325Fc3
Please list the members of your Alliance:
Kevin Owocki - Community Lead
Carl Barrdahl - Engineering Lead
Carey Murdock - Admin
Ceara Crawford - Ops
Nick Lioniss - Engineer
Octavian Todirut- Design
Previous Work
Our work is open-source: https://github.com/supermodularxyz
We are part of the Rapid Prototyping Pod, a sub-group of Gitcoin’s Ecosystem Collective (formerly known as WEST/Supermodular). We are focused on doing lean 0 to 1 build outs in the regen ecosystem.

EasyRetroPGF which came out of OP RPGF3

https://easyretropgf.xyz/

Gitcoin - which has funded $50m worth of ecosystem public goods.

https://impact.gitcoin.co

Smaller stuff:

SquareVote

https://squarevote.app/

QuadHoney - an experimental mobile Quadratic Voting webapp built for ETHDenver

https://qf-flash.vercel.app

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

What makes your Alliance best-suited to execute this Mission?
Proven Track Record in Regen Ecosystem

Gitcoin has funneled $60m into ecosystem public goods, demonstrating our team’s proficiency in managing broad impact projects in open source communities.
Array of projects show thoughtful but focussed execution (as above)

Alignment With Mission

Ongoing efforts in developing discovery and voting for RPGF
Already doing some of this work, such as impact metric queries integration into Gitcoin Grants Stack - and a whole series of podcast episodes about impact = profit.
Alignment with Optimism

Strategic Value Add

We are closely mirroring Optimism's development cycle for EasyRetroPGF and are familiar with the cadence due to pre-established relationships.
Ecosystem dynamics and other partnerships (Agora, for example)

TLDR:
Our Alliance's combo of a proven track record, alignment with mission requirements, strategic value addition, and a comprehensive understanding of the ecosystem dynamics positions us to execute this mission quickly and effectively while considering long-term impact and maintenance. Through leveraging our existing infrastructure, community engagement expertise, and strategic partnerships, we are equipped to drive the mission to success without question.
Please describe your proposed solution based on the above Solution Criteria:
We build everything in public so progress can be followed on GitHub and the latest deployed build.
TechStack

Next.js
Tailwind.css
React Query - great declarative async state handler with caching
Wagmi / RainbowKit
React Hook Form - performant form handling with schema validation
Prisma
Postgres
Vercel

Why these?

Battle-tested - used it large-scale production systems
Great documentation - easy to learn and understand codebase and onboard devs
Ecosystem - others have built on it and easy to find help and answers to questions
Great developer experience - powerful and fun to build with

Metric Discovery, Selection, and Weighting
Use Case

Optimism provides a collection of eligible projects as EAS attestations (similar to RFP3)
The user creates a filter of different impact metrics important to them. For example:

+100 Github Stars
+300 onchain users last 6 months
+1000 tx last 6 months

This filter is sent to OpenSourceObserver API along with the collection of eligible projects. The response contains the impact metric values for each project. We will work with OSO to explore ways to query their data based on the needs of RPGF4.
A score is calculated for each project from these values.
The vote distribution across the projects will be shown as a graph on the voting confirmation page.

Sounds nice, but how?

Dynamic Metric Weighting Interface: Drag and drop to prioritize all metrics.

Flexible Metric Prioritization: Allow users to choose any number of top metrics (1 to 5), not forcing a selection of five if they prefer fewer. Adjust weighting interface dynamically based on the number of metrics selected.

This is how they might also search by a single query

Direct Input for Precise Filtering: For users who want to quantify metrics (e.g., ">300 onchain users in the last 6 months"), provide input fields alongside sliders/pie charts for precise criteria setting. This should be optional use.
Sorting Options: Enable sorting by individual metrics in ascending or descending order. Include a "matrix sort" option where projects are ranked based on the composite score of the selected metrics as per above.
Advanced Filtering: Users can apply filters based on specific criteria (e.g., projects with >1000 transactions in the last 6 months) for targeted discovery.

Autopopulate Vote Allocation

Initial Allocation Algo: Based on their metric prioritization, weight the metrics and multiply but the success factor (# users, # txs, etc). Then, automatically suggest a vote allocation across all available projects, sorting them according to the combined weightage score derived from the user’s metric priorities.

Implement a sliding scale or pie chart for users to select and weight their top X projects. This visual approach simplifies the complexity of vote allocation.

Flexible Editable Allocation: Allow users to edit their vote allocation with input or moveable fields for easy adjustments, ensuring amounts auto-adjust across projects as changes are made, and offer the flexibility to select and modify project choices before finalizing the ballot.
Submit Ballot: The ballot of votes is created based on the selected impact metrics and weights and sent to the voting API. The badgeholder is redirected on success to a confirmation screen where they can review their published ballot and project allocation graph.

Additional Considerations

Responsive Design: Ensure the interface is intuitive and accessible on both desktop and mobile.
User Guidance: Throughout the metric selection and weighting process, provide tooltips and help icons explaining each metric and the impact of weighting. Separate onboarding documentation should not be necessary - if it’s complex, we’ve done it wrong.
Preview/Test Mode: Before submitting, offer a preview of how their votes are allocated, including a summary of their weighted metrics and the resulting project rankings.
Simplification for Beginners: For users overwhelmed by choices, offer an "Easy Mode" where the system recommends a set of balanced weights across key metrics or focuses on a single metric they prioritize.
Technical Robustness: Use React Hook Form for efficient form handling, React Query for state management with caching (to maintain user selections across sessions), and a flexible backend to dynamically adjust to user-inputted weights and criteria.

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work:
Phase 0: Submission Selection: (April 12 - Apr 20, 2024)

Scour insights on current desires and uses of visuals and metrics on OP from community forums, Reddit, and other chat spaces. Set tone for a community-driven process.
Research best practices on voting systems (prioritize accessibility and blockchain security). Benchmark UX external to OP and Web3.
Read and understand provided user stories, designs, and requirements.

Phase 1: Design, Prototype, User Testing: (April 17 - May 20)

Early prototype development - Apr 30, 2024.
Create codebase, GitHub repo, and Vercel deployment
Community feedback - Host AMA or webinar with GTC and OP community to gather feedback.Run customer interviews from highly engaged badgeholders.
Incorporate feedback: May 10, 2024.
Impact Metric Configurator development: aiming for completion by May 17, 2024.
Beta version: May 17, 2024.

Phase 2: Prototype and MVP Refinement with Voting Active: (May 20 - June 15)

Ballot submit and confirmation implemented: May 20, 2024.
Launch Potential Partnership Features: May 24, 2024.

Strategic Partnership Features - tested with “coming soon” modules, see what gets most clicks/votes. Could trial voting mechanism with this?!

Onboarding process development begins: May 30, 2024.
MVP Feedback with Badgeholders: June 5, 2024
Begin feedback incorporation.

Phase 3: Product Refinement, Full Launch, Results: (June 15 - June 28++)

Refine with badgeholder feedback and testing.
Launch Readiness with quiet soft launch: Jun 18, 2024.
Internal QA testing + fixes (scheduled for completion by May 31, but flexibility to align with feedback and continuity).
Results Ready Product: Jun 28, 2024.
Badgeholder feedback session: June 28, 2024
Results pour in.

Beyond Phases: Post Launch: (June 28 - Oct 31)

Voting monitoring and support: June 28, 2023 - July 14, 2024.

Results announced: Oct 1, 2024

aligning with the phase's end for a comprehensive review

Future Roadmap by Oct 15, 2024.

Continue to explore partner integrations.
Continuous support and documentation.
Feedback mechanism for improvements.

EasyRetroPGF.xyz integration

Make the feature set built in the spec available to users of EasyRetroPGF.xyz

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:
Community Engagement & Initial Prototype Completion (By May 4, 2024)

Community feedback gathered and analyzed
Early prototype developed and shared

Beta Version & Strategic Partnership Roadmap (By May 20, 2024)
MVP Launch with Badgeholder Feedback (By May 30, 2024)
Advanced search and user-friendly metric weighting implemented
Final Product Launch Ready for Voting (By June 12, 2024)
Voting functionality fully operational
Results Ready Product and Post-Launch Support Initiation (By June 19, 2024)
Final product capable of displaying results
Future Development Roadmap Presentation (By October 15, 2024)
Post-launch support mechanisms initiated
Please list any additional support your team would require to execute this mission:

We worked with Jonas quite closely in Round 3. We would love to continue working with him in the future

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

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

Alliance Lead: Andrew Jiang
Contact info<EMAIL_ADDRESS>L2 recipient address: 0x554edB0CC899bb87356d3D9e32a693afB31d384B

Please list the members of your Alliance and link to any previous work:
We are three cofounders that have worked together for 8+ years building high quality consumer and enterprise products that have millions of users.

Andrew Jiang is the cofounder and GP of Curated.xyz, a $51m crypto art fund. He’s an experienced builder, founding YC-backed Bayes Impact and responsible for building Driftershoots’ dapp and smart contract for his $7m open edition First Day Out.
Kevin Marlow is a senior software engineer at Angellist where he builds products and tooling for fund stakeholders and GPs to manage their participation in Angellist funds.
Jesse Sum is the founder of PlaceholderSoft, a product development studio that has built mobile and web applications, including Popshoplive, Passes.com, and DuraFi.

PlaceholderSoft has 20+ engineers and designers that we can scale up as needed.

Our application is supported and sponsored by Yitao Zhang, cofounder of Agora.

Previous web3 projects:

Gifted.art - Luxury digital art gifting platform built by Jesse and Andrew.
Noun266.xyz - Full experience for Noun266, including website, minting experience, and smart contract.
Curated Explorer - The best digital gallery experience for viewing digital art online.
Driftershoots.com - Website and minting app for Driftershoots, including the smart contract and dapp for his record breaking $7m open edition FirstDayOut.

Previous client work:

Passes.com - Website and app
Popshoplive - Mobile application
Windows Collaboration Display - Operating system and main applications for the Windows Collaboration Display by Sharp
LivMote - Enterprise grade touchless temperature monitoring. Built hardware and software applications.

What makes your Alliance best-suited to execute this Mission?
Success for this mission is building a voting platform that's performant, beautiful, and most importantly gives the voters the proper context and information to engage in a new experimental voting format. It requires fast iteration and user testing, much like any startup product. Our team has worked together as cofounders for 8+ years, have shipped web products used by millions of users:

Track record of building high quality consumer facing software.
Relevant experience building highly performant stakeholder management software, specifically a fund admin platform for investors to manage their participation in funds and investments (Angellist).
Demonstrated results building Web3 projects with beautiful interfaces that have high visibility and dollar impact.
Additionally, we run a full development studio of 20+ engineers and designers as needed.

Please describe your proposed solution based on the above Solution Criteria:
While we would want to spend time with the OP team to dive deeper into requirements, here’s our initial proposed solution based on the Mission Request and evaluation of data source:

Onboarding: The onboarding process is arguably the highest impact aspect of the product to ensure a successful voting experience. We would explore an onboarding experience that starts with a “prep room” along with a guided tour once the user enters the voting experience.

Prep Room (Optional) - The first time the user lands in the platform, they’re in the prep room. They’re provided with onboarding information that helps set the context of the experience, along with other details (e.g. impact metrics definitions) they can dive into if interested.

Introduction video explaining what impact metric based voting is.
Animated demonstration of how voting works
Materials that explain what the impact metrics are and how they’re derived

Some impact metric discovery happens in this part of the onboarding experience.

Guided Tour - After the user leaves the onboarding room and lands in the voting experience, we present a guided tour of the voting interface, pointing out key areas as well as going through the voting process.

Discover Impact Metrics: Impact metric discovery should happen across the experience, starting with the onboarding flow and also discoverable during the voting process. We think this is the single most important thing to get right — make the user fully understand what they’re basing their votes on.

Onboarding - As mentioned previously, impact metrics information could be included in the prep room before the user enters the voting experience.
Voting Side Bar - We would explore a searchable side bar list of impact metrics, with card pop ups that explain each impact metric, share the sources of data, and could even have video / audio of someone explaining the impact metric.
Tech Notes:

Fetching impact metrics from Open Source Observer API.

Endpoint: https://opensource-observer.hasura.app/v1/graphql
query GetCodeMetrics {
  code_metrics_by_project(
    limit: 10
    order_by: { avg_active_devs_6_months: desc_nulls_last }
  ) {
    project_id
    project_name
    # FULL LIST OF IMPACT METRICS #
  }
}

View & Edit Ballot: Ballot adjustment should be a smooth experience, starting with the selection of impact metrics. We’d build simple weight selection for each selected impact metric along with a live graph visualization of how the weights select impact OP distribution.

Edge Case Handling - We may want to enable ways for the user to make exceptions for projects that have unique reasons why they spike or are deficient on particular metrics. That includes ways for the voter to override metrics for any project and ways to flag metrics outliers.
Tech notes:

List of eligible projects from Agora API:

GET /api/v1/retropgf/round/:roundID/projects

Fetching impact metrics from Open Source Observer API (same as in Discover Impact Metrics).

Submit Ballot: Ballot submission should present a final summary of how they voted and the impact of their vote. Shareable modals for social media (X, Farcaster, Lens) can be included as well.

Optional Zora mint upon completion?
Tech notes:

Ballot Submission using Agora API:

POST /api/v1/retropgf/round/:roundID/ballot/:addressOrENSName/submit

Testing Mode: No additional product notes here.

Community Ballot Review: Not mentioned in the Mission Request, but can be fleshed out to be viewable, searchable, and copyable to a Badgeholder’s own ballot.

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

Scope, Specs and Requirements Clarification (April 17th - 19th):

Collaborate with the OP team to clarify requirements and finalize the design.
Define the scope and technical specifications for the voting client.

Design & Core Development Phase 1 (April 20th - May 17th):

UX/UI design following existing designs and requirements given
Develop the core functionality of the voting client, including onboarding, discovering impact metrics, and viewing/editing ballots.
Integrate Agora's API for voting functionality and Open Source Observer's API for impact metrics.

Testing & Iteration Phase 1 (May 18th - 24th):

Conduct internal testing and debugging.
Make necessary adjustments based on the testing results.

Prototype & User Testing (May 25st - 31st):

Finish the prototype of the voting client.
Conduct user interviews with at least 5 badgeholders to gather feedback.

Development & Integration Phase 2 (May 31st - June 23rd):

Implement feedback from user testing to refine the voting client.
Finalize the voting client for the voting phase.

Voting Phase (June 24th - July 8th):

Launch voting client for badgeholders to use for voting in Retro Funding Round 4.
Monitor the voting process and provide support as needed.

Post-Voting Phase (July 8th - 14th):

Finalize results display for the Results Phase.

Results Phase (July 15th - October):

Display the results of Retro Funding Round 4.
Continuously update and maintain the voting client as needed until the completion of the mission.

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

Launch of open source repository at the start of the project (April 17th, 2024)
First iteration of Figma designs published (~April 30th, 2024)
Working prototype for initial testing live on staging site (~May 17th)
Recorded notes from 5 user interviews published (~May 31st)
Publish app analytics and uptime monitoring (~June 24th)
Publish results display (July 15th)

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

We have a list of initial questions that need to be answered to complete the scope and requirements, along with being provided the mentioned existing designs.
As the Agora API is still in development until early May, we’d need to work closely with the Agora team to ensure our design works with the in progress API.

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 have no issues here.

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

Retro Funding 4 Voting UI
Foundation Mission (RFP) Application
Please verify that you meet the qualifications for submitting at the above Tier: ✅
Alliance Lead: Varit Ruangsiri, Curia Lab
Contact info<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>L2 recipient address:
Please list the members of your Alliance and link to any previous work:
Our Alliance, formed through a collaboration between Curia Lab and the Catalyzt team, is dedicated to enhancing the Optimism Retro Funding mechanism. Our joint effort focuses on the development of a Retro Funding Voting UI, leveraging advanced data analytics with an intuitive user experience (UX), aiming to empower the collective with the ability to make informed decisions. This initiative is dedicated to helping enrich the mechanism for supporting public goods, facilitating a more impactful and strategic allocation of resources.

Curia Lab: Curia Lab is a dynamic team composed of DAO governance researchers, data analysts, blockchain engineers, and developers. United by a shared mission to advance the DAO ecosystem, we offer specialized tools, in-depth insights, and dedicated delegate services. Our efforts are tailored to empower DAO communities, facilitating their evolution through strategic support and innovative solutions.

Catalyzt: Catalyzt is a team of builders that focuses on creating impact-driven governance tools for the Optimism Collective. Our expertise lies in developing tools and platforms that help assess the impact of projects and create collaboration between builders and ecosystems. With a focus on fostering meaningful innovation and supporting the Optimism community, Catalyzt is committed to advancing projects that have a lasting and positive effect across the OP ecosystem and Superchain.

For this project, the team will consist of the following:

Varit Ruangsiri (v3naru.eth) - Alliance Lead
Ratchanon Tarawan  (Billy191)  - Product Lead & Full Stack Developer
Jarukit Jintanasathirakul (wit03)  - Full Stack Developer
Jirayu Rungruang - Full Stack Developer
TGRZiminiar - Integration Engineer
Apemon - Data & Smart Contract Engineer
Kamin Prakob - UI/UX-Focused Developer & Designer
Natthaphum Tulyaanukij - Product Manager
Other roles may be filled as needed

Here are some of our past work:

Impact Calculator The product tools help Optimists/Badgeholders calculate project impact accurately by using data. This results in a streamlined RetroPGF process based on the axiom of “impact = reward”.

RetroPGF Hub A platform to nominate and discover projects that are making a positive impact on the world. Furthermore, it is the central hub for Optimists and the broader community to engage, explore, discover, and stay informed about all things related to Optimism’s Retro Funding (RetroPGF).

Builder Ideas A collection of project ideas aligned with various categories, from developer tooling to protocol experiments, is listed on a website by Optimism Foundation, OP Labs, and Base.

OP Governance Analytics Dashboard A tailored-made governance analytics dashboard that offers the OP Collective's governance dynamics with key metrics for informed decision-making.

SafeDAO Governance Analytics Dashboard A tailored-made governance analytics dashboard that offers SafeDAO's governance dynamics with key metrics for informed decision-making.

What makes your Alliance best-suited to execute this Mission?
Our alliance stands uniquely positioned to spearhead the Retro Funding Voting UI mission, underpinned by our intrinsic ties to the Optimism Collective and a shared history of impactful contributions. Here’s why we believe we are the ideal fit for this mission:

Proven Track Record in Building RetroPGF database and Impact Calculator: The Catalyzt team's work on the RetroPGF Hub, which successfully received over 45,000 OP during RetroPGF3 based on its perceived impact to the Optimism Collective, illustrates our strong commitment and contribution to the OP Collective. Along with the Impact Calculator, these tools showcase our ability to develop solutions that genuinely resonate with and benefit the Optimism ecosystem.Our expertise in crafting user-centric solutions and leveraging analytics for impact assessment ensures that our contributions are both meaningful and practical. Additionally, while building the Impact calculator prototype - we’ve worked closely with the OP Foundation and the OpenSource Observer team which has provided us with a significant head start and an in-depth understanding of the necessary features and functionalities for the voting UI prototype.

Direct Experience and Insight: Through Varit’s (v3naru.eth) active participation as an RPGF Badgeholder, our team brings firsthand experience and insight into the Retro Funding process's nuanced challenges and opportunities. This direct involvement ensures that our approach is deeply rooted in real user feedback, enabling us to target and alleviate the most significant pain points effectively. Additionally, having been recipients in previous rounds, our unique dual perspective enriches our understanding, allowing us to address the needs and concerns of both badgeholders and project contributors comprehensively.

Advanced Analytics and Governance Expertise: Curia Lab's development of the Governance Analytics Dashboard exemplifies our proficiency in analytics and deep understanding of governance. Our project, a highlight of Season 4, garnered the highest votes under Intent 4 from the Token House, receiving over 21.75 million OP votes, underscoring robust community support and trust. This support translated into substantial funding of over 90,000 OP from RetroPGF3, affirming the value and impact of our contributions. Feedback from the community has been overwhelmingly positive, which can be reviewed in detail here.

Additionally, we also have experience in working with the Agora team building on top of their data. For instance, we’re the first dashboard to integrate their latest partial delegation features into our dashboard demonstrating our technical proficiency and eagerness to leverage data for informed decision-making.
Furthermore, Curia's active participation as a top 100 delegate in the Token House, combined with our consistent presence in every governance call, affords us a comprehensive understanding of the governance dynamics within the Optimism ecosystem. This unique vantage point enables us to grasp the nuances of interactions between the Citizen House and the Token House, enriching our approach to enhancing governance participation and effectiveness.

Engagement and Community Insight: Billy (Billy191) has been serving as a Support Nerd and an Optimism Ambassador even before OP governance and OP Token were introduced. This demonstrates our commitment to actively engage with the Optimism community. Our engagement is crucial in gathering feedback and insights, which helps us refine and enhance the user interface based on community needs and preferences.

Deep Optimism Ecosystem Integration: As a collective of Optimism natives, our alliance embodies a deep understanding and commitment to the ecosystem. Our projects and initiatives reflect a dedication to fostering growth and innovation within Optimism, aligning perfectly with the mission's objectives.

Together, our alliance marries Curia Lab's governance involvement and analytical prowess with Catalyzt's innovative problem-solving skills and experience in developing impactful tools. This synergy of strengths equips us to deliver a Retro Funding Voting UI that not only meets but exceeds the community's expectations. Our collaborative efforts aim to enhance governance participation, ensuring a more inclusive, informed, and effective Retro Funding process. Our commitment to the Optimism ecosystem, combined with our comprehensive suite of skills and experiences, makes us the optimal choice to undertake this vital mission.
Please describe your proposed solution based on the above Solution Criteria (if applicable):
Our proposed solution for the Retro Funding Voting UI is designed to provide an intuitive, effective, and user-centric voting experience. The solution encompasses several key components, structured to address all critical aspects of the user journey from onboarding to final ballot submission.
Techstack:

The platform uses a technology stack that is trusted by the industry and designed for enterprise-grade applications. It benefits from ongoing innovation and support from a large developer network. The platform has unparalleled scalability and guaranteed uptime, thanks to Vercel and Cloudflare. In addition, it uses RainbowKit or Wagmi for security authorization with the wallet, which is globally recognized in the blockchain space.

Frontend

Data Management / Visualization

Authorization

Deployment/Security

Monitoring

Next.js

GraphQL / Apollo

RainbowKit

Vercel

Google Analytics

Tailwind (CSS)

Highchart.js

Wagmi

Cloudflare

Grafana/Prometheus

HeadlessUI

MongoDB

SIWE

Jotai

Onboarding:

Interactive Tutorial: Upon entering the voting UI, badgeholders will be guided through an interactive tutorial. This step-by-step walkthrough is designed to familiarize users with the overall interface, the mechanics of voting, the significance of each impact metric, and how each algorithm calculation works. The tutorial will be dynamic, adjusting content based on the user's progress and areas of interest.

Project Selection:

Project Dashboard: Each project eligible for voting will have a detailed dashboard that presents key data and analytics in an easily digestible format. This includes historical performance metrics, project impact scores, and other relevant data fetched in real-time from Open Source Observer’s APIs. These dashboards will enable badgeholders to make informed decisions by providing a holistic view of each project’s contributions and potential impact.

Project Sets: Recognizing the diversity in project types and the unique evaluation needs of each, we have revamped our project selection process. This enhancement is based on direct community feedback, highlighting the necessity for a tailored approach to metric evaluation. In our new system, users can create and customize multiple project sets, allowing for flexible categorization based on project types.

For instance, within the "Retro Funding 4: Onchain Builders" session, users can organize projects into distinct sets such as DeFi Projects, Infrastructure Projects, and NFT Projects. Each of these sets will utilize a specific set of impact metrics chosen by the user to best evaluate the projects within that category. For example, the DeFi Projects Set might focus on metrics like transaction volume and Total Value Locked (TVL), which are critical indicators of DeFi success but may not be relevant for Infrastructure or NFT projects. This flexibility allows badgeholders to apply the most appropriate and effective metrics to different project types, enhancing the accuracy and relevance of their evaluations.

Discover Impact Metric:
Our approach to discovering impact metrics is designed to optimize ease of use in evaluating the impacts of projects eligible for Retro Funding. This component is crucial in enabling badgeholders to make informed and impactful decisions.
Source and Integration of Metrics:
Impact metrics will be primarily sourced from Open Source Observer's dataset, accessible via their GraphQL API. If additional data sources are needed to enhance the evaluation, we will integrate these seamlessly to ensure a robust metrics framework.
From the last RPGF round, some badgeholders feel the need to spread their focus across their unfamiliar domain to accomplish the project instead of focusing on their expertise. To accommodate the expertise levels on each project among the badgeholders and simplifying the metric selection process, we will offer two distinct methods for selecting and weighting impact metrics:

Method 1: Metric Preferences Quiz:

Objective: To simplify the initial setup and make the selection process more intuitive.
Method: Badgeholders will be guided through an interactive quiz, modeled on personality assessment tools like the 16 Personalities test.
Benefit: This method reduces complexity and personalizes the voting experience, making it accessible and engaging for badgeholders with diverse backgrounds.

Method 2: Manual Selection:

Objective: To provide full control and flexibility to badgeholders who prefer a hands-on approach.
Method: This option allows badgeholders to manually choose and assign weights to each impact metric according to their assessed value & priorities.
Benefit: Enables experienced users or those with specific insights to fine-tune their ballots to reflect a nuanced understanding of project impacts.

Allocation Algorithms:
After the result of RPGF3, there was a debate on the ideal allocation calculation with various preferences. To accommodate different preferences for impact evaluation, we explored three distinct allocation algorithms. Each is designed to cater to various goals of distribution fairness and effectiveness, allowing badgeholders to select the method that best aligns with their objectives.

Linear Weighted Average:

This method allocates resources based on direct performance metrics, rewarding projects linearly according to their score or output. The higher the score, the higher the allocation, following a power law distribution where a small number of top performers receive most of the resources.
Distribution: Power Law
Pros: Directly correlates funding with performance, providing clear incentives for achieving high metrics.
Cons: This can lead to significant disparities in funding, as top performers receive exponentially more resources, potentially marginalizing smaller or emerging projects that could also have a substantial impact.

Logarithmic Weighted Average:

This approach modifies the power law distribution by applying a logarithmic scale to performance scores. This reduces the steepness of resource allocation seen in the linear approach, helping to level the playing field somewhat.
Distribution: Smoothed-out Exponential
Pros: Reduces the gap between the highest and average performers, making funding more accessible to a broader range of projects.
Cons: Although it reduces disparity, it may still not be enough to adequately support lower-performing projects that have potential, and could blur significant performance differences.

Percentile-based Approach:

Funds are distributed based on the percentile ranking of projects, rather than absolute scores. This approach aims to normalize the distribution, where the allocation curve resembles a bell-shaped Gaussian distribution, ensuring a more equitable spread across all participating projects.
Distribution: Gaussian
Pros: Creates a balanced funding environment where projects are rewarded relative to their peers, promoting fairness.
Cons: May overly smooth out funding differences, potentially under-rewarding top performers and over-rewarding lower performers relative to their actual impact or output.

All badgeholders can now choose allocation calculations, and the final distribution and allocation results of each project will be shown before the ballot is finalized.

View & Edit Ballot:

Badgeholders can easily manage and review their selections through a user-friendly dashboard that provides a comprehensive summary of all the projects and their respective allocations in their ballot. This interface will present projects in both list and card formats for clarity and ease of use.
Key Features:

Secure Sign-In: Badgeholders authenticate via their wallets (RainbowKit / SIWE) to ensure secure and private access to their ballots.
Interactive Editing: Users can intuitively adjust their allocations—adding or removing projects and changing funding amounts—with immediate visual feedback on how these changes affect the overall distribution.
Save and Manage: Changes can be saved at any time, allowing badgeholders to return and adjust their ballot as needed before final submission.

Submit Ballot:
To streamline the ballot submission and ensure seamless integration, we will collaborate closely with the Agora team. As ballots are submitted, Agora's API will manage the secure transmission and storage of data, providing badgeholders with immediate feedback and confirmation of their submissions.

Post-Submission Feedback: Immediately after submitting their ballots, badgeholders will be encouraged to provide feedback. This information will be instrumental in continuously refining the voting interface and process, ensuring it remains responsive to user needs and effective in future rounds.
Optional Ballot Sharing: After submitting their ballot, badgeholders will have the option to export their ballot choices into a shareable format. This feature allows them to easily post their voting decisions on the governance forums, and social media channels like X (Twitter) or Farcaster. By enabling badgeholders to share their voting rationale publicly, we foster greater transparency and community discussion around voting choices.

Ballot and Projects Attestation:
Our UI enables robust community engagement by allowing users to issue on-chain attestations for both projects and badgeholders' ballots (if applicable):

Attestation for Ballots: If the Optimism Foundation permits visibility of individual ballots, our voting UI will feature an on-chain attestation functionality. This allows the community members to comment on or endorse the ballots of badgeholders. Such attestations would provide a robust, transparent community feedback and support mechanism.

Attestation for Projects: Independent of ballot visibility, our UI will enable community members to issue on-chain attestations for projects that have applied for Retro Funding. This feature allows users to endorse projects they believe in or provide constructive feedback to the projects. These attestations will be visible on each project’s page, allowing other users to view and consider these endorsements and comments.

Testing Mode:
All non-badgeholders will have access to a sandbox environment where they can explore the voting UI. This tool will educate the community, increase engagement, and provide a better understanding of the Retro Funding process.
Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work:
We have already started working on the project with our initial design prototype and functional prototype. For the execution plan, we have decided to split into two sub-track and work in parallel to complete this mission. Assume that our team has been selected to work on this mission. Here are the step-by-step phases to work on
Phase 1: Design and Prototyping (April 17th - April 24th)
Objective: Establish the foundation for the UI/UX of the voting system.
Tasks:

Collaborate with UX/UI designers to create high-fidelity mockups in Figma.
(Started)

Hi-Fi Mockup (WIP)

Conduct initial user feedback sessions with potential badgeholders.

Finalize interactive user flow diagrams.

Deliverable: A design specification document with finalized designs and user flow diagrams.
Phase 2: Development and Technical Integration (April 25th - May 20th)
Objective: Develop the core technical infrastructure and integrate external data APIs.
Tasks:

Set up development environments for frontend..
Begin frontend coding based on Figma designs.
Integrate Open Source Observer data via API.
Develop dynamic metric addition and weighting functionalities.

Deliverable: A working prototype of the voting UI with API integration.
Phase 3: Testing and Initial Feedback (May 21st - May 31st)
Objective: Test the MVP with badgeholders and integrate voting functionality using Agora’s API.
Tasks:

Implement and test Agora API integration for voting functionalities.
Conduct MVP testing with badgeholders to collect feedback.
Iterate on the prototype based on the feedback.

Deliverable: MVP tested and ready for further refinement.
Phase 4: Final Improvements and Preparation for Launch (June 1st - June 20th)
Objective: Refine the application based on MVP feedback and prepare for public launch.
Tasks:

Analyze feedback from MVP testing and make necessary adjustments.
Conduct additional rounds of testing.
Finalize preparations for public deployment.

Deliverable: An enhanced version of the voting UI ready for public release.
Phase 5: Public Launch and Monitoring (June 21st - July 8th)
Objective: Deploy the voting UI publicly and monitor its performance.
Tasks:

Deploy the enhanced voting UI to production.
Monitor performance and user interactions.
Collect ongoing feedback for future iterations.

Deliverable: Official public release of the voting UI with a performance report.
Phase 6: Results, Feedback, and Future Enhancements (July 15th - October)
Objective: Announce voting results, gather detailed user feedback, and plan future enhancements.
Tasks:

Compile and announce the results of the voting process.
Organize detailed feedback sessions with users.
Prepare a detailed report evaluating the tool’s impact and gather insights for improvement.

Deliverable: Comprehensive analysis report on voting outcomes and feedback for future development.
Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

Critical Milestone

Description

Verification

Due Date

Source of truth

UX/UI Design

Overall designs of the platform, user flow, core features, and metric preferences quiz.

UX/UI design should cover all the necessary features and pages for the platform.

April 24th, 2024

Figma

Platform Development Progress (Before Agora API integration)

Core functionality will be implemented with mockup data while waiting for application results.

Core functionality, excluding API integration, should be available.

May 20th, 2024

GitHub

MVP Testing with Badgeholder

The testing will cover user flow, project sets, matric lists, graphs, and allocation results to optimize the platform’s user-centric design.

The platform had been tested with at least 5 Badgeholders.

May 31st, 2024

Bagdeholders feedback.

Platform Launch

The platform is now publicly launched for badgeholders to evaluate projects for Retro Funding 4.

The platform is launched with full functionality.

June 21st, 2024

GitHub

Result

All recipients for Retro Funding 4 are announced.

The platform displayed voting results.

July 15th, 2024

Site

Please list any additional support your team would require to execute this mission (financial, technical, etc.):
We seek support from the OP team primarily in product testing and feedback collection to ensure our voting UI meets community standards and expectations. Besides, badgeholders feedback, collaborative testing, and insight gathering with the OP team would be crucial for refining our UI, aligning it closely with user needs, and enhancing its effectiveness within the Retro Funding process.
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.)
We don't need any upfront capital to complete and execute this mission since we have received previous retro funding rounds that cover all of this! Thank you for Optimism’s funding process.
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

Foundation Mission (RFP) Application
Please verify that you meet the qualifications for submitting at the above Tier
RetroList has received 49k OP in RetroPGF 3

Alliance Lead: Chomtana Chanjaraswichai
Contact info<EMAIL_ADDRESS>L2 recipient address:

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

Chomtana Chanjaraswichai - Team Lead, Smart Contract Developer - TechNerd, RetroList, simple-optimism-node, Opti.domains and more...
Frong - Full Stack Developer - Has experience developing many dApps anonymously
Kittikorn Keeratikriengkrai - Frontend Developer - RetroList, Inspex Lighthouse
Poonpetch Luancharoen - UX/UI Designer - RetroList, Inspex Lighthouse

What makes your Alliance best-suited to execute this Mission?
RetroList has developed a project discovery and rubric based list evaluation system in the last Season. We have integrated with Agora API in a smart way with our unique caching technique such that RetroList isn't down while the Agora API is down.
RetroList can be seen as a community alternative of RetroPGF voting UI that allow community to participate in the RetroPGF voting
Please describe your proposed solution based on the above Solution Criteria (if applicable):
We will develop a metric based RetroPGF voting UI according to the spec and design with an exact follow. We would host in a different website specially for the official RetroPGF voting UI
We will give comment if we see things that are inappropriate. We would also incorporate badgeholder feedback and provide support in the discord on the voting period.
Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work:

Develop core functionalities
Interview at least 5 badgeholders
Collect and incorporate badgeholder reviews
Deploy voting UI to production and sandbox environment
Monitor and provide support in the discord along the voting period
Develop voting result UI
Deploy and publish voting result UI

Deadline is set according to the requirement. Please see critical milestones below
Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:
Open Source repository

Source of truth: Github Repository
Deadline: May 1st

Prototype for user testing

Source of truth: UI Deployment
Deadline: May 31st

5+ Badgeholder interviews

Source of truth: Interview video published on the forum
Deadline: June 7th

Live Voting UI

Source of truth: UI Deployment
Deadline: June 23rd

Result UI

Source of truth: UI Deployment
Deadline: July 14th

Please list any additional support your team would require to execute this mission (financial, technical, etc.):
We would like to have a telegram group with Jonas and all stakeholders with high priority.
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.)
No
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

Hi all – thanks for the excellent submissions and discussion! 🌞
The Optimism Foundation has selected Owocki's proposal https://github.com/ethereum-optimism/ecosystem-contributions/issues/173#issuecomment-2050284605 to move forward with the work described in this Foundation Mission. 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 are lots of open Delegate Mission requests and you can expect more Foundation Missions to follow soon. In addition, there are builder ideas, which provide guidance on contributions which are valueble to the Collective and could be Retro Funded.

Perfect choice- congrats @owocki and team! <3
Will definitely use whatever you guys build, haha!
Looking forward to seeing this go live.

Congrats @owocki and Gitcoin team! Can't wait what you're going to build. Again, congratulations 🥊

Great choice and congrats to @owocki and team!

An update from our team:

Github repo up at: https://github.com/gitcoinco/op-rf4-voting-ui
Deployment at: https://op-rf4-voting-ui.vercel.app/
Working on building the ballot metrics editor to enable voters to add and remove metrics and adjust their allocation in percentage. (turns out, dynamic form + increment and decrement buttons are trickier than initially thought. had some issues with inputs losing focus on tabbing due to re-renders. Fixed by using controllers instead of setValue directly)
Feedback form stepper when submitting ballot is almost done
Working on implementing Agora API so currently just mock data

Foundation Mission (RFP) Application
What makes your Alliance best-suited to execute this Mission?

Expertise in Web3 and Blockchain Technology: BitKe specializes in the innovation of Web3 products and has a proven track record of empowering entrepreneurs and individuals with cutting-edge blockchain and cryptocurrency solutions, making us well-equipped to develop and refine the Retro Funding 4 Voting UI.
Focused on Governance Accessibility: Our commitment to providing Web3 information and knowledge across multiple media channels aligns with the mission's goal of enhancing governance accessibility, ensuring that badgeholders can easily understand and engage with the new metric-based voting system.

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

Intuitive Voting Client: BitKe will develop a user-friendly frontend for badgeholders, featuring a seamless onboarding flow, easy discovery and selection of impact metrics, and a clear visualization of ballot decisions, ensuring an efficient and transparent voting process.
Robust Technical Integration: Leveraging Agora’s API for voting functionality and Open Source Observer’s API for impact metrics, our solution will ensure accurate, real-time updates and reliable ballot submission, supporting all phases from prototype testing to final result display.

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

Phase
Details
Date

Phase 1: Prototype & User Testing

Initial Development
Develop the core functionality of the voting client, including onboarding, impact metric discovery, and ballot management. Integrate Agora’s API for voting functionality and Open Source Observer’s API for impact metrics.
May 1 - May 15, 2024

User Testing Preparation
Prepare a prototype for user testing. Select and brief at least 5 badgeholders for user interviews.
May 16 - May 30, 2024

Prototype Launch
Conduct user testing and gather feedback. Analyze user feedback to refine the voting client.
May 31, 2024

Phase 2: Voting

Iterative Improvements
Implement improvements based on user feedback. Ensure robustness and reliability of the voting client.
June 1 - June 15, 2024

Final Preparations
Conduct final tests and quality assurance. Prepare documentation and support resources for badgeholders.
June 16 - June 23, 2024

Voting Period
Monitor the voting process and provide technical support. Collect data on badgeholder interactions and voting metrics.
June 24 - July 8, 2024

Phase 3: Results

Data Analysis
Analyze voting data to ensure accuracy and integrity. Prepare visualizations and reports for badgeholders.
July 9 - July 14, 2024

Results Display
Develop and launch the results display functionality. Provide ongoing support and updates as necessary.
July 15 - July 31, 2024

Post-voting Analysis and Reporting
Collect qualitative feedback from badgeholders via surveys. Compile a comprehensive report on the voting experience and outcomes. Make open-source code repository and final reports available for review.
August 1 - October 31, 2024

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

Milestone 1 - Prototype & User Testing Launch (May 31, 2024): Completion of core voting client functionality including onboarding, metric discovery, and ballot management. Integration with Agora’s API and Open Source Observer’s API. Conducting at least 5 user interviews with badgeholders to gather feedback and refine the prototype.
Milestone 2 - Voting Phase Launch (June 24, 2024): Implementation of improvements based on user feedback. Final testing and quality assurance completed. Voting client operational and available for badgeholders to vote during the designated period.
Milestone 3 - Results Display (July 15, 2024): Accurate and reliable analysis of voting data. Development and deployment of the results display functionality within the voting client.
Milestone 4 - Post-Voting Analysis and Reporting (October 31, 2024): Collection of qualitative feedback from badgeholders via surveys. Compilation and publication of a comprehensive report on the voting experience and outcomes. Maintenance of an open-source code repository and documentation for transparency and future reference.

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

Technical Support: Access to Agora's API documentation and technical assistance for seamless integration of voting functionalities and impact metrics.
Financial Support: Additional funding for user testing, including incentives for badgeholders participating in feedback sessions and ensuring robust testing infrastructure.

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.)

Upfront Capital Requirement: Yes, access to upfront capital would facilitate the initial development phase, including prototyping and user testing, ensuring timely and effective execution of the mission.

The Voting has taken place, you can check out the voting UI here round4.optimism.io 👈

Hello we are trying to track the status of applications on the
https://round4.optimism.io/ but we can't find it
On Wed, Aug 7, 2024 at 7:23 PM Jonas Seiferth @.***>
wrote:

Closed #173
https://github.com/ethereum-optimism/ecosystem-contributions/issues/173
as completed.
—
Reply to this email directly, view it on GitHub
https://github.com/ethereum-optimism/ecosystem-contributions/issues/173#event-13794970703,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AI5MKYFKSQRSFG2CITSZDULZQJCX5AVCNFSM6AAAAABFZMCQGGVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJTG44TIOJXGA3TAMY
.
You are receiving this because you commented.Message ID:
<ethereum-optimism/ecosystem-contributions/issue/173/issue_event/13794970703
@github.com>


Remove instructions to copy Etcd CA key in HA

No need to copy etcd CA key when manually copying certs from first master node to nodes joining the control plane.
https://github.com/kubernetes/kubernetes/blob/release-1.17/cmd/kubeadm/app/phases/copycerts/copycerts.go#L191-L198
@neolit123

/sig cluster-lifecycle
/cc @fabriziopandini

/check-cla

if it still does not work after adding the CLA email to your github account you need to contact the CNCF help desk.
then type /check-cla again here

/check-cla

thanks for the update @yacinelazaar !
/lgtm
/assign @steveperry-53

/approve


Typo in Docs

Issue type
I'm submitting a ...

[x] bug report
[ ] feature request

I think there is a typo in the docs where it is @kitten/ui & I think it should be react-native-ui-kitten.
Link → https://akveo.github.io/react-native-ui-kitten/docs/guides/create-ui-kitten-screen#modify-styles

Thanks!

Just noticed this today and it kept crashing my APP. 👍

@taslimy we already have a pr for it


Try to bump version to fix https://github.com/tonerdo/coverlet/issues/452

Should fix https://github.com/tonerdo/coverlet/issues/452
cc: @AdmiringWorm

close because not viable.


run just with CPU

Is it possible to run Bitcrack with a CPU?
actually, I have an 8-core CPU. Is this potential to run BitCrack 8 times on every CPU core?
thanks

Here is a bitcrack that can run on cpus
https://github.com/unclevito2017/VanitySearch-bitcrack
Here uis a Bitcrack program that is suppose to work on AMD.
https://github.com/BitCrackEvo/BitCrackEvo

Salaam alaikum to everyone!
Hello everyone!
Bitcoin is a scam!
On March 19, 2024, 865 bitcoins were sold on the exchange at a price of $8,000!
On other exchanges the price was $70,000!
Let's create a community and sequentially select the private key of the largest bts address!
And when we find it, Bitcoin will collapse!
Thanks in advance everyone!


How to extend selenium2library in Java

I would like to know if there is proper approach to extend this library to include new keyword (supported by selenium driver) without changing the original code?
Thanks for the library.

You can create your own jar with following test library.
Note: In your test case, you must import the Selenium2Library first then import ExtendedSelenium2Library.
import java.util.List;

import javax.script.ScriptException;

import org.openqa.selenium.WebElement;

import com.github.markusbernhardt.selenium2library.keywords.BrowserManagement;
import com.github.markusbernhardt.selenium2library.keywords.Element;
import com.github.markusbernhardt.selenium2library.locators.ElementFinder;

public class ExtendedSelenium2Library {
	private Selenium2Library sel2;
	private BrowserManagement browserManagement;
	private Element element;

	public ExtendedSelenium2Library() throws ScriptException {
		sel2 = (Selenium2Library) Selenium2Library.getLibraryInstance();
		browserManagement = sel2.getBrowserManagement();
		element = sel2.getElement();
		// ...
	}

	public void myKeyword() {
		// call Selenium2Library api
		System.out.println(browserManagement.getTitle());
		System.out.println(element.getValue("name=btnK"));

		// call selenium api
		List<WebElement> elements = ElementFinder.find(
				browserManagement.getCurrentWebDriver(), "id=lst-ib");
		elements.get(0).sendKeys("Cheese!");
	}
}

*** Settings ***
Library           Selenium2Library
Library           ExtendedSelenium2Library

*** Test Cases ***
Test1
    open browser    http://www.google.com    ie
    My Keyword
    Submit Form    id=tsf
    #close browser

Hi Mark,
how to use selenium2library with testng i,e in @Test  annotation

I'm trying to do this on my project but I'm getting a null WebDriver object, and not sure why.
I created this class:
public class Extended {
	private Selenium2Library sel2;
	private BrowserManagement browserManagement;
	private Element element;
	private org.openqa.selenium.WebDriver driver;  //this one is from Selenium, not Selenium2Library

	public Extended() throws ScriptException {
		try {
			sel2 = (Selenium2Library) Selenium2Library.getLibraryInstance();
		} catch (javax.script.ScriptException e) {
			e.printStackTrace();
		}
		browserManagement = sel2.getBrowserManagement();
                driver=browserManagement.getCurrentWebDriver();
                element = sel2.getElement();
    }
}

First weird thing is that I get this warning:

Access restriction: The type 'ScriptException' is not API (restriction on required library 'C:\Program Files\Java\jdk1.8.0_131\jre\lib\rt.jar')

Then, if I add a breakpoint right after the driver=browserManagement.getCurrentWebDriver(); line and debug, I can clearly see how this driver object is null.
Not sure if it's relevant, but since I use Maven, I haven't manually installed anything and all my project setup is in pom.xml, where I've included selenium-java from org.seleniumhq.selenium and robotframework-selenium2library-java from com.github.markusbernhardt, as well as the robotframework-maven-plugin from org.robotframework.

Have you imported the Selenium2Library before your test library in your test case? The import order is very important.
*** Settings ***
Library           Selenium2Library
Library           sample.ExtendedSelenium2Library