flâneur

Rute Figueiredo

0 followers · 251 views

on the atlas — 8

highlights — 61

  • Customers won’t search for your release notes, so we need a way to deliver them, and that’s the “release note pipeline”.
    How to Write Better Release Notes for SaaS
  • Tell the story of your new feature or update visually. In a video, you can show a quick tutorial on how to use a new software product. Screenshots and GIFs are great for simple changes, bug fixes, and small features. Visual elements can be beneficial in explaining your product release and help you keep text to a minimum.
    How to Write Better Release Notes for SaaS
  • Add photos, GIFs, infographics, in app screenshots, or short demo videos to help solidify the information, set an example, and make it clear what improvement has been made and where they can find it, add relevant links.
    How to Write Better Release Notes for SaaS
  • Make your release notes as concise and to the point as possible. Focus on sharing the end value for customers. Hey! Even try to make your release notes fun.
    How to Write Better Release Notes for SaaS
  • Release notes are like letters your team sends to your customers about known issues, a release date, company news, a future new version launch, software improvements, feature enhancements, product changes, etc.
    How to Write Better Release Notes for SaaS
  • The purpose of release notes. Release notes serve several purposes like: Product release notes to inform about the launch of new features or the latest version of a product. Periodical in app announcements to keep users aware of the regular changes in your product and development cycle. Reports about technical details to sustain brand trust like bug fixes, performance improvements, security issues, and other tech improvements.
    How to Write Better Release Notes for SaaS
  • 11. Automate changelog generation Keeping a consistent cadence of updates is a challenge for high-velocity teams. With all the tasks included in shipping product updates, it’s easy for the changelog to be deprioritized.
    11 Best Practices for Changelogs
  • Regular reviews allow you to maintain your changelog as a reliable source of information, catch inaccuracies, incorporate user feedback, and stay aligned with the evolving nature of your product, ultimately enhancing the credibility and usefulness of your changelog.
    11 Best Practices for Changelogs
  • A changelog is like a window to your shop: the examples of the best changelogs are regularly updated to showcase the latest and greatest updates in your collection. Not only will it inspire your loyal customers to keep coming back, but also invite prospects to explore what more your product has to offer.
    11 Best Practices for Changelogs
  • 10. Review and update regularly.
    11 Best Practices for Changelogs
  • 9. Use bullet points. Using bullet points to succinctly provide information goes hand in hand with being clear and concise. The changelog format where the information is broken down into bullet points not only simplifies complex details but also provides a visually appealing format that is readable and easy to understand.
    11 Best Practices for Changelogs
  • 8. Provide information about end-user impact. Your users want to know how changes will impact their users. When you fail to communicate end-user impact in your changelog, you can expect your inbox to be filled with questions from concerned customers who care deeply about providing a seamless experience to their end-users.
    11 Best Practices for Changelogs
  • To ensure that your team is staying true to the right formatting, create style guides and release note templates (or use one of our own).
    11 Best Practices for Changelogs
  • 7. Use a consistent format. Consistency breeds familiarity. Using a consistent changelog format not only enhances readability but also establishes a recognizable style that users can quickly adapt to, creating a cohesive and user-friendly experience.
    11 Best Practices for Changelogs
  • 6. Provide links to relevant resources.
    11 Best Practices for Changelogs
  • Avoid over-complication by having few and straightforward categories. For example, using tags like “added,” “changed,” “deprecated,” and “removed” will quickly signify the type of change being made.
    11 Best Practices for Changelogs
  • By categorizing changes, like we do in the changelog example below, you create a user-friendly changelog layout that facilitates efficient navigation, ensuring that users can easily locate and comprehend the updates most relevant to them.
    11 Best Practices for Changelogs
  • 5. Categorize changes to align with changelog best practices.
    11 Best Practices for Changelogs
  • What is the value proposition of this update? What benefits will users have from this change in your product? List all of the potential results that it can generate, from how it will impact user experience to how it will benefit end users.
    11 Best Practices for Changelogs
  • What pain points does this update address? What challenge or problem does this release resolve? If addressing a frustration previously voiced by users via feedback, make it clear.
    11 Best Practices for Changelogs
  • What pain points does this update address? What challenge or problem does this release resolve? If addressing a frustration previously voiced by users via feedback, make it clear.
    11 Best Practices for Changelogs
  • Who is the target audience of this update? Which user segment will this update impact the most or be most interesting to? If dealing with various audiences with differing style preferences, consider segmenting your updates to tailor the communication.
    11 Best Practices for Changelogs
  • What does this update communicate? Is it a new feature release, a product enhancement, or a bug fix? The language must be consistent with that of other updates in the same category.
    11 Best Practices for Changelogs
  • 4. Use clear and concise language. Clarity is key and users appreciate straightforward language that communicates product changes effectively. Even though some product updates can be very technical, your target audience might not be. Avoiding jargon and unnecessary detail can foster understanding and engagement.
    11 Best Practices for Changelogs
  • 4. Use clear and concise language.
    11 Best Practices for Changelogs
  • If your user base is global, consider including time zone information to avoid ambiguity. Alternatively, use Coordinated Universal Time (UTC) to provide a standardized reference point.
    11 Best Practices for Changelogs
  • 3. Date each release. Dates matter. Providing a clear timeline not only informs users about the frequency of updates but also establishes a sense of reliability.
    11 Best Practices for Changelogs
  • A clear and consistent versioning strategy helps users understand the significance of updates and makes it easier to manage software dependencies.
    11 Best Practices for Changelogs
  • Alpha, Beta, Release Candidate (RC): Used for pre-release versions to represent the stage of product development. Alpha versions are early releases with incomplete features, beta versions are more stable but may still have bugs, and release candidates are considered almost ready for the final release pending user testing.
    11 Best Practices for Changelogs
  • Semantic versioning (SemVer): Consists of three numbers separated by dots (e.g., 1.2.3) that represent major, minor, and patch versions. Major versions indicate significant changes, minor versions signify backward-compatible features, and patch versions denote bug fixes.
    11 Best Practices for Changelogs
  • Determine the versioning strategy. Deciding on a versioning strategy is not just about numbers. It provides a structured way to convey information about the evolution and changes in the software to both internal teams and users.
    11 Best Practices for Changelogs
  • By starting with the latest version of product updates, you immediately grab your users’ attention and set a positive tone for the rest of the changelog, enhancing the overall user experience.
    11 Best Practices for Changelogs
  • Aztec operates on three types of circuits: Private kernel circuits, which are executed by the user on their own device and prove correct execution of a function Public kernel circuits, which are executed by the sequencer and ensure the stack trace of transactions adheres to function execution rules Rollup circuits, which bundle all of the Aztec transactions into a proof that can be efficiently verified on Ethereum
    What is Aztec? | Privacy-first zkRollup | Aztec Documentation
  • Aztec allows private communications with Ethereum - ie no-one knows where the transaction is coming from, just that it is coming from somewhere on Aztec.
    What is Aztec? | Privacy-first zkRollup | Aztec Documentation
  • Private state works with UTXOs, or what we call notes.
    What is Aztec? | Privacy-first zkRollup | Aztec Documentation
  • Working with private state is creating commitments and nullifiers to state, whereas working with public state is directly updating state
    What is Aztec? | Privacy-first zkRollup | Aztec Documentation
  • To handle these problems, arithmetic circuits are calculated over finite fields: a branch of mathematics where all addition and multiplication is done modulo a prime number.
    Arithmetic Circuits for ZK
  • If the solution to every problem in NP can be modeled with a Boolean circuit and every Boolean circuit can be transformed into an equivalent arithmetic circuit, then it follows that the solution to every problem in NP can be modeled with an arithmetic circuit. In practice, ZK developers prefer to use arithmetic circuits over Boolean circuits because, as shown in the examples above, they generally require fewer variables to accomplish the same task. There is no need to calculate a Boolean circuit and then transform it into an arithmetic circuit. We can model the solution to the NP problem with …
    Arithmetic Circuits for ZK
  • Final arithmetic circuit to check if u ≥ v is as follows.
    Arithmetic Circuits for ZK
  • To demonstrate arithmetic circuits and Boolean circuits are equivalent, we will later show that any Boolean circuit can be transformed into an arithmetic circuit. This shows they can be used interchangeably for the purpose of demonstrating an agent has a witness to a problem in P or NP.
    Arithmetic Circuits for ZK
  • Let’s revisit our example above: writing a Boolean circuit to represent the equation a + b = c, where we’re given c = 24. For a Boolean circuit, we need to encode a, b and c in binary, which requires 4 bits each. In total, we have 12 inputs to the circuit. By comparison, the arithmetic circuit only requires 3 inputs: a, b, and c. This reduction in the number of inputs, and also in the size of the circuit, is the reason we opt to use arithmetic circuits for ZK applications.
    Arithmetic Circuits for ZK
  • A useful mental model for the arithmetic circuit is that all signals are treated as inputs without outputs.
    Arithmetic Circuits for ZK
  • The agent proving the validity of their witness can assign any values to signals. However, their proof (witness) will only be considered valid if all the constraints are met.
    Arithmetic Circuits for ZK
  • We emphasize that the === is asserting the left-hand side and right-hand side are equal. For example, in the following circuit: c === a + b we are not adding a to b and assigning it to c. We assume that the values a, b, and c are provided as inputs, and we are asserting a relationship between them holds. This has the effect of constraining the sum of a and b to be c. Think of the c === a + b as being completely equivalent to assertEq(c, a + b). Similarly, the expression a + b === c * d is completely equivalent to assertEq(a + b, c * d).
    Arithmetic Circuits for ZK
  • Variables in an arithmetic circuit are referred to as signals.
    Arithmetic Circuits for ZK
  • We say a Boolean circuit is satisfied if we have an assignment to the input variables that results in an output of true. Similarly, an arithmetic circuit is satisfied if there is an assignment to the variables such that all the equations hold true.
    Arithmetic Circuits for ZK
  • An arithmetic circuit is a system of equations using only addition, multiplication, and equality. Like a Boolean circuit, it checks that a proposed set of inputs is valid, but doesn’t compute a solution.
    Arithmetic Circuits for ZK
  • The size of the Boolean formula is important. Going back to our chess example, if you try to model every state with a Boolean formula, then the size of your formula will be exponentially large. Therefore, the only feasible problems are NP or P, which have reasonably sized Boolean formulas that model them.
    P vs NP and its application to zero knowledge proofs
  • All problems with solutions that can be quickly verified can be converted into a Boolean formula.
    P vs NP and its application to zero knowledge proofs
  • it can help you prove to another party you have a solution, if you already computed it.
    P vs NP and its application to zero knowledge proofs