Replies: 2 comments
-
|
Partial and full are only referencing the time range/block count. As for the difference in points for full and partial hyperion, With the new system, you would get +2 points instead of +1. We only want guilds to run full history if they really have the hardware to handle it, hence we only wanted to grant the bonus if the uptime is >= 95%. So a partial Hyperion is: full Hyperion would be: Our reasoning is, that we don't want guilds to have barely used/usable endpoints that end up with 3 points because of 71% uptime based on validations. |
Beta Was this translation helpful? Give feedback.
-
|
based on a public conversation the following tech-ops criteria has been updated: Hyperion features needed to apply scoring for hyperion based solutions:
|
Beta Was this translation helpful? Give feedback.
-
[v4.5] Office of Inspector General Guidelines [DRAFT]
The Office of Inspector General (OIG) is a neutral third-party role designed to evaluate WAX Guild Candidates' contribution to the ecosystem and provide ongoing transparency for the community. The office is designed as a committee with 3 inspector generals who will standardize WAX Guild evaluations, and properly recognise those WAX Guilds making valuable contributions to the WAX ecosystem.
Guilds that failed the previous evaluation and don't submit an update will not be reviewed, marked as Failed Core and moved to Retired Guilds table.
a) underlined text represents additions / modifications.
b)
text with strikethrough represents removals.c)
code block text represents proposed changes that have not reached consensus yet.Major Changes in v4.5 - mid October 2022
Technical Requirements
We are announcing changes to the scoring of history solutions. See the following table for an overview.
TX history APIs eligible for points:
v1 nativeScoring of history solutions happens based on the following criteria:
Additional APIs (e.g. Light API) can be scored under the category ‘useful APIs’), if usage metrics are provided and support a scoring.Guilds are responsible to ensure their history solutions uptime and performance is successfully tracked by the majority of monitoring systems ([https://tools.ledgerwise.io/](https://tools.ledgerwise.io/), [https://wax.validationcore.io/stats/guild](https://wax.validationcore.io/stats/guild), [https://oig.sentnl.io/](https://oig.sentnl.io/), [https://wax.stats.eosusa.news/](https://wax.stats.eosusa.news/)). Failing to do so can result in a loss of points.This means guilds need to ensure their bp.json is available and updated and their rate limits are tolerant enough to allow the fulfilment of all checks. If tracking fails and the situation can not be resolved in a timely manner Guilds should provide an explanation and the measures taken with their next report.Hyperion features needed to apply scoring for hyperion based solutions:
Evaluation Process
Guilds will be evaluated on a regular basis on the criteria below. The committee will publish the cutoff date for rating Guilds each evaluation cycle. Guilds will submit their update and appeals to Github in plain text with links to data/screenshots. Confidential information can be submitted via email, but requires to be noted in the public update. Publishing an update with non-confidential information is mandatory if you want the OIG to evaluate your confidential sections. Rating appeals are to be provided as Github issues.
The criteria will consist of line items in a range of categories with various point ranges. The committee believes this will make it easier to evaluate Guilds fairly.
The OIG does however have to rely on the reported information to be accurate. Points credited under false pretense due to wrong information being submitted or important changes not being communicated may result in a penalty. Submission of inaccurate information during reports or appeals where the OIG has to assume the goal is to scrounge evaluation scores may also result in a penalty. This includes, but does not conclude with: The misrepresentation of development efforts, development progress, purported collaborations or partnerships, knowingly boasting the significance of a products based on false claims, fakery of infrastructure availability or performance.
If no time range is specified, the last evaluation time frame is applied, starting with the last evaluation report release, ending with the submission cut off date.
The pre-evaluation and minimum requirements must be fulfilled to be considered for a rating. Satisfied criteria will improve a Guild's score on the report.
Guilds, that failed an evaluation based on minimum requirements, are granted the opportunity to apply for reinstatement. This can only be done once within an evaluation period, after addressing all outstanding issues and providing a stable service for 7 days. Guilds that have been in a Top 21 position by score during the previous evaluation, that (a) fail minimum requirements but (b) achieve the required minimum score and (c) have their issues addressed before the end of the appeal period, will instead of failing be demoted to a standby position.
While active producers can claim their pay daily based on produced blocks, Guilds in standby positions are paid on a monthly basis. To be eligible for payments, Guilds need to pass the minimum requirements of each month, verifying they offered a service over the paid evaluation period. Severly failing to uphold minimum requirements, or being unregistered, for a prolonged time over an evaluation period while otherwise still passing minimum requirements, can result in a proportionate share of the standby rewards getting deducted. This also applies to reinstatement periods when minimum requirements have not been met towards the end of an evaluation period. Reinstatements are always evaluated based on testnet performance. For this timeframe Guilds are considered unregistered from WAX mainnet, no matter if they actually are or not.
Score Threshold
(P)re-Evaluation Requirements
Minimum Requirements
Seed node endpoint is available for peering.Secondary Requirements
All criteria are specific to the WAX network and ecosystem unless otherwise stated.
Confidentiality
If required, information can be submitted to the IGs confidentially via email; Confidential submissions must still be noted in the public report published on github.
Tiebreaker Resolution
If two guilds are tied for a rank, the tie is resolved by looking at the points scored in the previous evaluation. The guild with a higher score in the previous month is determined to be the winner of the tie.
Technical Operations
Professionalism on the technical operations front. Technical Operations encompasses running all required services in a secure configuration, meeting the performance demands of the network, coordinating with other guilds to test and upgrade the network, providing publicly available infrastructure, and implementing processes to minimize risk and maximize availability. If not stated otherwise all
Required Skills
Systems engineering and infrastructure management (TechOps), Information Security (InfoSec), IT Admin (CorpSec)
Criteria
Product Development
Measurable software engineering and product development for the WAX ecosystem. This involves creating primarily open source tools and services to benefit the entire WAX network, such as wallets, interactive bots, and data analysis tools.
Guilds can score points for a maximum of 5 products. Only tools and products that bring real value to the network will be considered based on the following:
User metrics, service, and value provided, open source code, WAX focus, tokenomic contribution (e.g. DeFi fees).
Only one new product can be submitted per evaluation period. New product submissions are only accepted if existing products are properly maintained or have been discontinued. New products exceeding the size of community tools, expected to earn more than 2 points, should be introduced to the OIG in a product discovery call ahead of their first submission.
For the initial submission of a new product, Guilds should provide as much information as possible, including a roadmap and development plans.
and verifiable metrics. which will be tracked in their Guild's product sheet.All following submissions must only contain updates, changes to previously reported information, additions and metrics. Full resubmissions with minor changes will be ignored.For a product to be considered released, it must be usable, working, and demonstrate a user base.
Products under development that wish to be considered for points require a product discovery call and must provide a monthly update containing progress, blockers (if any), and timelines. These points are only granted for a maximum of three evaluation cycles. Exceptions can be made for bigger projects that are expected to contribute significant value to the ecosystem, extending the eligibility to six evaluation cycles.
If a guild does not manage to fulfill their promise of release on the planed schedule they will be granted an extension that aligns with the original timeframe with no points credited.
Failing to release the product by the end of the extension given will result in the previously granted points being applied as a penalty over the following evaluations at half the original rate.
A successfully released product can be awarded points for a specified period of time
beyond releaseuntil it eventually decays to a minimum threshold for as long as it's maintained and maintenance is reported upon. Decay can be offset by ongoing feature releases and development. Products that stall or die will not earn points. Whether a project has stalled or died will be judged based on the quality of monthly updates (and therein contained metrics) regarding the product.Products will be scored in categories, including but not limited to Tools, Standards, Widgets, Blockbusters, Multimedia, and evaluated based on UX, Innovation, Adoption, and Reach.
Guilds that split the responsibilities for a larger product may share points, depending on circumstances. Guilds working together will be expected to explain what each Guild is doing on the project to earn points. Points will be split based on the ratio provided by the guilds in question. If no ratio is provided, the points will be distributed equally. Guilds are asked to appoint a project owner. If no project owner is appointed, both parties need to agree on distribution changes. If guilds can not come to an agreement, they can 'contest' project points.
In case of project points being contested, both guilds will lose an equal amount of points until a co-signed agreement is submitted to the OIG. Points can only be contested for the following evaluation period, leaving involved parties one evaluation period to find an agreement without points being lost.
Required Skills
Software Programming, Development Operations (DevOps), Systems and Infrastructure Management
Criteria
Product Sheet Template
Product Development Criteria
Ecosystem Development
Bringing businesses, products, and liquidity to the WAX network or providing a Service supporting others doing so. Actively facilitating integrations into the larger blockchain ecosystem with services such as: wallet providers, major exchanges, and interoperable DApps. Getting funds interested in the project. Providing publicly known and available services and hands-on assistance to businesses in the WAX ecosystem.
Required Skills
Business Development, Finance, Product Partnerships, Product Development
Criteria
Guilds can earn ED points for a maximum of 5 activities and services. Only activities that add value to the network will be considered, based on user metrics, service and value provided, open source code, and WAX focus.
Guild must provide as much information as possible, such as MOUs, proof of correspondence, and updates about the progress of the engagement, which will be tracked in their Guild's ED sheet. Only Engagements that can be verified may eligible to earn points before closure.
Engagements will be evaluated continually and and may remain eligible to earn points for a specified period of time. Engagements that stall or die will not earn points. Whether a project has stalled or died will be judged based on the quality of monthly updates regarding the engagement. Submitted engagements should have passed a lead stage and should have entered integration.
Efforts that don't require a lot of time and labor, and build marginal value for WAX, will be deemed a "small engagement" and worth less points than a big deal.
Guilds who split the responsibilities for a larger engagement may share points, depending on circumstances. Guilds working together will be expected to explain what each Guild is doing on the project to earn points. Points will be split based on the ratio provided by the guilds in question. If no ratio is provided, the points will be distributed equally.
Successfully concluded engagements can be awarded points for a specified period of time beyond closure before it eventually decays.
Ecosystem Development Sheet Template
Ecosystem Development Criteria
WAX Strategic Contributions (0 to 10)
Contributions that bring outstanding value to the WAX ecosystem in the following categories:
Strategic points are only awarded for Products or Engagements that already score the maximum points in their respective category.
Scoring System
Each of the aforementioned categories will be scored according to the multipliers outlined below. Ultimately, the candidates with the highest scores are considered the most valuable Guilds to serve on the WAX blockchain.
[unchanged]
Beta Was this translation helpful? Give feedback.
All reactions