Try   HackMD

Default GitHub Labels

We use a modified sane labelling scheme as proposed here by Dave Lunny, along with inspiration from ManageIQ.

It's broken down into four different types of labels: status labels, release labels, type labels and change labels.

SRC | NIPs have their own labelling schema which are defined [here](todo: make 'here').

Status Labels

These are intended to cover a broad range of states that an issue may be in during different stages of development. Only one status label will be applied to a particular issue - for instance, something can't be both 'In Progress' and 'Abandoned'.

Label Hex Code Description
Status: Available Text This issue is currently available to be worked on.
Status: Revision This issue has not been completed, and needs to be revised as detailed in the comments.
Status: In Progress This issue is currently being worked on.
Status: On Hold This issue has been put on hold for reasons detailed in the comments.
Status: Review Needed This issue is waiting for a code review or design review.
Status: Blocked This is currently an issue that is unable to be resolved or worked on due to a blocker.
Status: Completed This issue has been completed and is awaiting scheduling for the next release candidate.
Status: Pending This issue is currently pending approval for the next release candidate.
Status: Abandoned This issue has been abandoned, for reasons detailed in the comments. When applied, this issue should be closed.
Status: Unmergeable The pull request is unmergeable, for reasons detailed in the comments.
Status: Stale This issue is old or hasn't had activity in >6 months.

Release Labels

These labels track an issue as it moves into testing (and eventually deployment).

Our product release process follows the below flow.

  1. Issues with the [Status: Completed] label are scheduled for review.
  2. Issues migrate from the [Release: Review] label to [Release: Testing] once they launched in testnet or in a test environment.
  3. Issues move to blocked once a problem has been found that needs further development. Move the issue back to [Status: Available].
  4. Issues migrate to [Release: Accepted] once they have passed testing and are ready to be scheduled in inclusion for an RC.
  5. Issues migrate to [Release: Pending] once they are scheduled for inclusion in a release candidate.
  6. Issues migrate to [Release: Live] once they're in mainnet (or otherwise released).
  7. Issues move to [Release: On-Hold] if they are currently not scheduled for inclusion in a release candidate.
                                                              ┌────────────┐
                                                              │            │
                                                              │  On-Hold   ├─────┐
                                                              │            │     │
                                                              └─────▲──────┘     │
                                                                    │            │
                                                                    │            │
                                                                    │            │
┌───────────┐       ┌────────────┐      ┌────────────┐        ┌─────┴──────┐     │
│           │       │            │      │            │        │            │     │
│  Review   ├───────►  Testing   ├──────►  Accepted  ├────────►  Pending   ◄─────┘
│           │       │            │      │            │        │            │
└─────▲─────┘       └─────┬──────┘      └────────────┘        └─────┬──────┘
      │                   │                                         │
      │                   │                                         │
      │             ┌─────▼──────┐                                  │
      │             │            │                            ┌─────▼──────┐
      └─────────────┤  Blocked   │                            │            │
                    │            │                            │    Live    │
                    └────────────┘                            │            │
                                                              └────────────┘

Release labels track where an issue in the release candidate process. Maintainers can use this to prepare their releases for inclusion in Milestones. These labels are exclusively for issues that have been 'completed'.

Label Hex Code Description
Release: Review Text This issue has been accepted for the next release candidate. Contrast with 'Status: Complete'.
Release: Testing This issue is currently in testing (QA & performance) with other issues in the review pipeline.
Release: Blocked This issue has failed testing or needs further development.
Release: Accepted This issue has been accepted for inclusion in a release candidate.
Release: Pending This issue is pending release.
Release: On-Hold This issue is currently on-hold.
Release: Live This issue is currently live and in production.

Type Labels

Label Hex Code Description
Type: Bug Not the ladybug kind, but the software gremlin kind.
Type: Sporadic Bug A bug that manifests as test failures unpredictably.
Type: NotABug This issue is not a bug as reported, or not reproducible. When applied, the issue should be closed.
Type: DevOps This issue is related to DevOps (such as AWS, CI/CD, network monitoring, logs).
Type: Enhancement An enhancement, new feature, or quality of life improvement.
Type: Design Issues or changes specifically related to design (including UX/UI, look-and-feel, and general art.)
Type: Duplicate This issue is a duplicate. When applied, the duplicate issue should be referenced in a comment.
Type: Help Wanted An issue that can be handled by anyone, even new members of the community.
Type: Question Issues that are just questions. When the question is resolved, the issue should be closed.
Type: Social Media Issues specifically related to social media and external communications.
Type: Tools Issues specifically related to internal tooling, such as Discord, Telegram, GitHub, CI/CD, etc.

Change Labels

These are intended to clearly articulate what the following PR changes. Think of these as user-facing labels - who, or what, is this change affecting?

Label Hex Code Description
Change: Cleanup Changes that only make the code cleaner and do not change how the code works, nor the outputs.
Change: Dependencies Changes that affect dependencies.
Change: Developer Changes that affect developers only, including non-customer-facing tools.
Change: Documentation Changes to documentation only.
Change: Internationalization Changes that are for internationalization only.
Change: Performance Changes that are for performance improvements only.
Change: Refactoring Changes in the way the code works internally without changing output. Contrast to 'Change: Cleanup'.
Change: Technical Debt Changes that remove or significantly update old unused code and/or dependencies.
Change: Frontend Changes to the frontend code of an application or website.
Change: User Experience Changes to the user experience or user flow of an application.
Change: Test Changes to test code only.
Change: Tools Changes to customer-facing tools. Contrast to 'Change: Developer'.

Questions

You might wonder why we don't have priority labels. Generally when priority labels are introduced, everything becomes a 'mission-critical-must-fix-now'. Priority labels also encourage laziness - if you own your code, you should know what is and isn't an urgent issue.

tags: Handbook Project Management Organization
Last changed by 
 
The Symbol Syndicate
We're the team behind Symbol, a next generation protocol for market makers. Join us.
3
1
346

Read more

Ramblings about public keys that were supposed to be twitter thread

Hello, @gimre here. We should probably change the way we display public keys in all possible applications/tools/etc. But before I dive into this, let's refresh your memory about addresses. This part is Symbol oriented, but it's also true for NEM. Addresses (again) Addresses in Symbol consist of 3 parts: 1-byte network prefix (0x68 byte in mainnet)

May 11, 2023
2023 02 27 NEM Stall Post Mortem

Observation After the production of block 4129631, block production on the NEM network slowed to a crawl. This situation was instigated by an unexpected transaction entering the Unconfirmed Transactions cache. When this transaction expired, block production went back to normal. We have identified the makeup of the unexpected transaction and how it entered the Unconfirmed Transactions cache. A multisig account configured with 1-of-2 multisig sent two conflicting transactaions. Assume that the two cosigners are named A and B and the multisig account is named M. Root Cause Analysis The following sequence of events occured:

Mar 22, 2023
A Guide to Creating a Symbol Test Network

Before any changes are deployed to Symbol mainnet or a new project gets launches on the blockchain, a test version is deployed to testnet first. Symbol test network(testnet) simulates the Symbol main network which gives developers and the community a chance to test features before real assets are used. Sai Testnet is the current testnet for Symbol. You can add a node and get test tokens from the Faucet. The Faucet allow an account to request up to 10k in test xym. If more token are needed to test or run a voting node, you can be requested from the Symbol's helpdesk on discord. It can be fun to have 3 or 4 million of test xym to splurge a bit, even though they carry no real-world value. Why should you create your own dev testnet? Creating and maintaining a Symbol testnet requires some work like certs and voting key renewals, so why bother setting up your own? These are some reasons you would want to setup your own dev testnet. Test Scenario - you might want to run specific test scenarios for your application. Let's say you want to fork the network and stall finalization to verify that your application also stops accepting deposits and withdrawals. Persistence - there is no guarantee that the testnet won't be reset. Symbol testnet is reset at least once a year to keep storage low. But it can also be reset if a major feature stops working. If your application requires the data kept for a longer time then a dev testnet would be better. Control Funds - your use case might require a large sum of funds like 500 Million xym. Even though there is the Faucet, requesting that much token is best done on dev testnet.

Dec 21, 2022
Symbol - October 25th, Post Mortem

Greetings, Citizens of XYM City! Find the Japanese translation here. The Discovery On October 13th, Toshi reported some unexpected behavior to us on Discord in the #sdk-js channel. He had been comparing the outputs of the deprecated TypeScript SDK to the newer JavaScript SDK and noticed that the aggregate transaction hashes were being calculated differently. That...was not expected behavior. Even more concerning was the fact that they were both being accepted (and confirmed) by the network. Root Cause The team quickly identified two critical bugs - one in Catapult (the Symbol client), and one in the TypeScript and Java SDKs.

Oct 26, 2022
Read more from The Symbol Syndicate
Published on HackMD