udaykiran19491/user-stories-from-tawos-for-llm-fine-tuning huggingface dataset:
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Given I am an Independent Identity Owner and I'm writing my first DID to the ledger, I should be required to: # Receive the Identity Owner Agreement (linked below)# Accept the Identity Owner Agreement by checking the boxes in the form# Send the accepted Identity Owner Agreement to 1. Receive the Independent Identity Owner Agreement here (https://docs.google.com/document/d/108RzMIUttXDooJR2CWrXDR-roF3wsk2eHvN-Iwxqq8k/edit#heading=h.s9fy0y2f2m3m) from my Trust Anchor2. I should be able to agree to it in a way that my Trust Anchor can see and verify."
Answer: 870426.0

User story: "Given I am a Trust Anchor, I should be able to:# create 1 million new identifiers on Sovrin in 3 hours. # I should have latency lower than 1 second for each transaction"
Answer: 870425.0

User story: "A LOCALIZED (not geographically dispersed) Sovrin Network should be able to:1. Handle a total of at least 1 million Identities using the Ledger for a verkey lookup transaction within 1 hour2. I should have local latency less than 10 milliseconds for each transaction."
Answer: 870426.0

User story: "Given I am a Trustee and a Trust Anchor makes a giant mistake, such as it creates millions of identifiers on accident, I along with other Trustees should be able to:# Recover by coming to agreement on modification of the ledger."
Answer: 870426.0

User story: This design should be a "Full Design" complete with vertical slices, such that we'll start with simple static validator pool, but then move to a dynamic validator pool that has dynamic promotion and demotion based on downed nodes and poor performance and reputation.We don't have to fully design all aspects of future concerns like node reputation, but we include a good idea of how those concerns will work together.
Answer: 870425.0

User story: "https://docs.google.com/document/d/1HcVp0V1RvgHanW_et84ttiga-eWkOaNyzhBzFwsWBIg/edit#"
Answer: 870427.0

User story: "Given I am a Trust Anchor acting as an Issuer I should be able to:  # send a special kind of Claim Offer: a Trust Anchor Invitation  # I should only be able to send this type of claim offer to an Independent Identity Owner (both Organizational and Individual)  # Given the Invitee accepts the invitation by sending in return a Claim Request  (covered in SOV-267), requesting I write a Public Claim of MY Trust Anchor Connection with the invitee. I should then be able to:  # Write a Public Claim of MY Trust Anchor Connection with the invitee to the Sovrin ledger.  # Send a message to the invitee pointing them to the Public Claim I wrote.  # When I receive the Claim Request, which is the invitee's Trust Anchor Invitation acceptance (after step 2), all remaining steps in this story should be automated and I should NOT be able to back out or cancel the invitation.  All terms are defined in the [Sovrin Trust Framework|https://docs.google.com/document/d/1n6if3-JZw8BaRmxm3B9X5mKj_IZPHLqi_khHFOrY-XA/edit#]"
Answer: 870426.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Given I am an Organizational Guardian (OG) (defined in the [Sovrin Trust Framework|https://docs.google.com/document/d/1n6if3-JZw8BaRmxm3B9X5mKj_IZPHLqi_khHFOrY-XA/edit#]), I should be able to establish a connection with a Partner Agency (PA).Assumptions: # OG and PA already have a legal services agreement signed.# PA already has a running agency.# PA has an agent for itself.# OG has already installed an agent on its premises.Steps:# PA generates a Connection Invitation (Offer?) and sends to OG out of band in the form of a .sovrin file.# The OG admin then loads the .sovrin invitation file into the OG agent and then accepts the invitation. This results in a Connection Request being sent to the PA through the agent connections. At this point, the OG's pairwise DID and key is written to Sovrin.# PA's agent receives and accepts the incoming Connection Request. It also writes its pairwise DID and key to Sovrin. It then sends a Connection Confirmation to OG’s agent.# OG’s agent records the connection.*[Plan of Attack|https://docs.google.com/document/d/17S5Qo78MpGBUN0UTh6dGzDyGNCTwZUW7LvZ-5vcQxJ0/edit]*"
Answer: 1149118.0

User story: "Our claims and proofs don't look like the Verifiable Claims spec. They should follow the VC spec with a special CL (Camenisch-Lysyanskaya) type signature.h4. [Plan of Attack|https://docs.google.com/document/d/1GrA_ah-rRtwjeEYipDtF4sV30JdapbQq6CdUqEtYYl0/edit]"
Answer: 870428.0

User story: "Placeholder for implementation of Full Design. This will need to be broken up into epics."
Answer: 870426.0

User story: "Today, our python code uses only one core. Because we use deques between processes, it lends itself fairly easily to a multi-process architecture. This story has us improving performance of nodes by leveraging more available cores on the server.h4. [Plan of Attack|https://docs.google.com/document/d/1KSJUkRbmYdUB0bx5_BULF5T8oRqKkuCNRY679JL9g7E/edit]"
Answer: 1178203.0

User story: "Implement a way to store and get tails for anoncreds revocation in Sovrin according to design completed in SOV-68."
Answer: 870428.0

User story: This builds on top of the [story|https://evernym.atlassian.net/browse/SOV-336] about having an MSI-based install. What we need is a way to issue a command that says, "install the latest version of sovrin" -- and then have the package manager go scan its repo(s) to decide what the latest version is, download the .msi-based package, and install it -- then keep track of what's installed so it can do future upgrades.h4. PoAPack the sovrin node and the dependencies in to chocolatey packages ([tutorial|https://github.com/chocolatey/choco/wiki/CreatePackages])
Answer: 870426.0

User story: "From Alex: We need to support Upgrading and wait until SOV-337 is complete."
Answer: 1152050.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "See #5f of the [Sovrin Platform Requirements MASTER|https://docs.google.com/document/d/1cglrYjY5UKWF7e5F1FhwOMoJLNGrShDHeoGw7PUama0/edit#] docAs a Technical Governance Board Member, I need to know when: # There are minor outages and which nodes in the network it is affecting# There are major outages and which nodes in the network they are affecting# When there are major outages, I should get an email to [email group name for all tech. gov. board members]. # I should see that the system is degrading gracefully from the outages. # I should see that the system is recovering gracefully from the outages."
Answer: 870426.0

User story: See #5.e.i of the [Sovrin Platform Requirements MASTER|https://docs.google.com/document/d/1cglrYjY5UKWF7e5F1FhwOMoJLNGrShDHeoGw7PUama0/edit#] docAs a Technical Governance Board Member, I need to know when: # There's unusual spikes in the network# There's unusual/weird behavior# If someone is trying to abuse the system by creating 1 million new ID requests per minute (for example)# If someone is doing way too many verkey lookups in a given amount of time (need to decide what "too many" means)# The usage ratio on the network changes in a significant way (we are suddenly doing way more of a given transaction type in proportion to the general mix). For example, we suddenly see a barrage of key revocations or key rotations.# The load on individual validators is skewed significantly (one validator is receiving almost all incoming requests, whereas other validators are never contacted). Note that this doesn't mean one validator is working hard while others are idle, because any request causes all the validators to work for consensus--it just means that we see weird shifts where all the initial requests of the network arrive on a subset of the validators.lower-level: a change in the retry ratio or the timeout ratio between validator nodes# There's a change in how often the network rejects requests because they are malformed (e.g., not signed properly, or lacking required parameters)
Answer: 870426.0

User story: See #5.b of the [Sovrin Platform Requirements MASTER|https://docs.google.com/document/d/1cglrYjY5UKWF7e5F1FhwOMoJLNGrShDHeoGw7PUama0/edit#] docAs a Technical Governance Board Member, I need to know: # Ongoing thru-put of the network# What/who are all the nodes in the system# How many nodes in the system# How many nodes are being slower than the network average# Average network speed (?)# Unusual spikes in traffic (relates to SOV-352 and SOV -351)# These above items are considered "general monitoring" and should be turned ON by default for my viewing.For POA person: *Look at Andrey G's GUI for guidance on completing this story*
Answer: 870426.0

User story: "*"
Answer: 870426.0

User story: "POA:- Setup MacOS machine- Configure MAcOS agent- Integrate MacOS agent into existing test pipelines"
Answer: 870426.0

User story: "Schema data type validationWe need to do proper data type validation when schema based value is exchanged between different parties."
Answer: 949618.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: When the "daemon" (i.e., `start_sovrin_node`) starts up, it should store its process ID into a `.pid` file.We should also properly clean up after the daemon as it exits.
Answer: 870426.0

User story: "When developers code against the ledger (going through sovclient.py or its Rust equivalent), they need to know whether their calls succeed or not. If they fail, the error conditions need to be communicated. Today, that communication is textual (an error message). That's a good start, but it is problematic in three ways:1. It can't be localized.2. If the text changes, consuming code that analyzes the error will break.3. There are important challenges to reliably build a knowledge base or refer to an error condition in a forum or stack overflow posts.I believe the solution to this is to associate every error with a number or code that is held invariant across changes to text. (I actually recommend numbers, possibly with a textual prefix, because that is the easiest to pass across a C-callable interface cheaply.)This is not necessarily vital for warnings or less severe logged events -- only for errors."
Answer: 870426.0

User story: "-There should be a provision in ZStack to not have a listener socket, Client’s NodeZStack does not need a listener socket."
Answer: 870426.0

User story: "After replacing RAET with ZMQ:For multipart messages where the addr of the remote socket is not known (listener in ClientZStack), the remote cannot be disconnected, the consequence is that the node cannot forcefully disconnect the client, need to find some way to either send a FIN flag or something else. This mailing list thread and its replies might help, https://lists.zeromq.org/pipermail/zeromq-dev/2016-August/030774.html. Some links from zyre codebase https://github.com/zeromq/zyre/blob/055219523325cef4e87941e07abc39718d7350e4/src/zyre_node.c#L555 and https://github.com/zeromq/zyre/blob/055219523325cef4e87941e07abc39718d7350e4/src/zyre_node.c#L948."
Answer: 870426.0

User story: "As a Steward, I should be able to: # Determine if a 'create new sovrin DID' transaction does NOT come from a DID authorized by a Trust Anchor# If #3 is true, I should be able to reject the transaction."
Answer: 870426.0

User story: Given I'm any type of User looking at the logs I should see: 1. A timestamp prefixed to every log message following ISO 86012. A time zone -3. Log in UTC-4. Replace the "T" with a space in the ISO standard5. Use a comma to separate the seconds and millisecondsExample: [2017-03-08 18:10:22,452+00:00] <log message here>*So that I can debug easier, know what time each log message was sent and so that Evernym has clearer log messages.*
Answer: 870426.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Currently the way blacklisting has been implemented we have created a single point of failure for a pool. To blacklist a node from the pool you need to be a Trustee or TGB member and it is a single transaction sent to the ledger. The intent is that the Trustees or TGB would come to a verbal consensus to blacklist a node in the pool. Then a single member can send a transaction to the pool to blacklist the node.*Issue:*The issue with this approach is that any one member has the ability to blacklist the pool down to 3 nodes. With only 3 nodes consensus cannot be reached on any transaction including adding back a node to the pool. *Possible Solution:*Instead of a single transaction maybe have two thirds of the Trustees or TGB members or a combination of both each send a transaction to blacklist a node. Once enough transaction requests for the same event occur that node can be blacklisted. This may not be the right approach it is just an example of how to possibly spread out the power."
Answer: 870426.0

User story: "As an Evernym or Sovrin Admin: 1. For every piece of software we have: Need to be able to specify the name and location for where the log files are stored 1a. Should be done in a config file. 2. Log rolling-  configuring by sizewhen they get to a certain size (should be configurable), save it off and create a new log file2a. By date - save logs from the past 30 days, etc3. Log rolling - configuring by time -risk of filling up partition -relies on #24. Log depth - configuring how many rolled logs I keep (in same config file) - relies on #25. specifiy the verbosity of the logs (log level)"
Answer: 870426.0

User story: See section marked # [sov-693] START - # [sov-693] END in the [Unicorn Phase 0 script|https://github.com/evernym/unicorn/blob/master/Unicorn_Phase_0_script].Given I am a CLI user acting as a Prover and I have at least one connection, I should be able to: # Generate a proof# That proof should automatically be generated from a simple file which looks similar to this:        Name: "new address"                Owner Name: Alice                1295 Billow lane road                Eagle Mountain, TX 58985       Issuer signature: [issuer sig goes here]       Issuer DID: [Issuer DID goes here]       Nonce: [nonce goes here]# I should be able to send that generated proof to my connections one at a time like the script shows.
Answer: 870428.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: This story includes implementing all parts of the [Unicorn Phase 0 script|https://github.com/evernym/unicorn/blob/master/Unicorn_Phase_0_script] in between the sov-694 START and sov-694 END markers. As a CLI Issuer having received a Claim Request, I should be able to:# Open and look at the claim request# Fulfill the claim request (which generates a Claim)# Send the Claim back to the requester (requester == Prover)# Use the above linked script for guidance on the exact CLI commands I should be able to type# Don't feel like the output has to be 100% exact matching the script. You may deviate on the actual format of the Claim Request and Claim itself, etc. Just keep the sentences the same like "Claim generated successfully". # The <-- within 2.0" means that output and the output after it should show up within 2 seconds of executing the previous command.
Answer: 870428.0

User story: "Following are the changes that needs to be done* Change {{request claim}} command to {{send claim request}}* Response of existing command gets the claim from Issuer and there is no step to accepts it. We need to modify this behaviour, to only get the claim and not accept it. By accept means we means that unaccepted claims cannot be used to generate proof. Only when a user accepts a claim, then it can be used to generate a claim.Things to be taken care of:* Until claim is accepted, it cannot be used in {{> show proof request}} or {{> fulfil proof request}}* Output of {{> show link}} command should output {{Available Claim(s):}} and {{Unaccepted Claim(s)}}. As of now we just show {{Available Claim(s)}}h2. [Plan of Attack|https://docs.google.com/document/d/1iFJ2DdfGcVwwm1kVF7Ke6INbGPFHqI7k7qHviHYeYkk/edit]"
Answer: 870426.0

User story: "Prover should be able to issue a command {{alice> accept claim <claim-name>}} to accept a claim. Accepted claims should be available to generate a proof. Output for {{alice> show claim}}, {{alice> show link}} should clearly specify the state of claim. In output of {{alice> show claim}} command Status should specify it as Accepted. Show link command should show accepted claim in Accepted claims line.h2. [Plan of Attack|https://docs.google.com/document/d/1wWGodhK7tT6eQKwwCpMNPnU15zq_wG4qSk4AuJcg2J0/edit]"
Answer: 870426.0

User story: "As of now plenum monitor can indicate that master is slow and we need a view change only if master is live but it performs poorly. We need to be able to tell that master degraded if it got disconnected."
Answer: 870426.0

User story: "As per unicorn's SOW requirement number 1.4.1.e: As a presenter presenting unicorn's phase0 demo script I should be able to:# Look at the transaction files in the ledger# Read and understand the transaction files in the ledger[Krishnan] The functionality is already in place. The estimate provided is to do the documentation to explain the contents of the ledger."
Answer: 870426.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Given there's a Sovrin Validator node that falls behind more than 1 version from the rest of the network, the network should collectively: # Kick out the node (automatically) that's behind until it upgrades# A Trustee (or the Steward of that node??) should be able to re-add the node back to the pool once it upgradesPoA:- Find a way to check that version of a node is below others for more than 1 (use NODE_UPGRADE txn?)- Find who checks that a particular node should be kicked out (the node itself, or the pool by some consensus)  Consider the following example: 4 nodes with versions 1.2.3, 1.2.2, 1.2.3, 1.2.1. Should we make sure that all nodes (even a node with 1.2.2) kicks out the node with version 1.2.1?- Find a time/place when we kick out a node (that is when we check that a version is too below): when we get NODE_UPGRADE txn, or at the startup, or check from time to time.- FInd how we kick out a node: just blacklist it?- Implement the proposed solution*Update:*On completion of each POOL_UPGRADE, each node checks whether other nodes are on an acceptable version by querying the ledger for NODE_UPGRADE txns, if they find they are not, they check if this POOL_UPGRADE can bring make node 1+ version, if yes they wait else not. Once they realise that some node is behind and they make an `OBSOLETE/OUTDATED` txn and once another node agrees that node has fallen behind on the upgrade, it also sends `OBSOLETE` txn.There needs to be configuration parameter specifying how long can a node stay outdated?"
Answer: 870426.0

User story: "As of now we run test for plenum with [a custom test runner|https://github.com/evernym/plenum/blob/master/runner.py]. We should refactor this runner so that in produces an xml in junit format, move it from plenum to jenkins-shared to be accesible for any repo and update our pipelines accordingly"
Answer: 870426.0

User story: "After migration to Jenkins we no longer do a programmatic validation of dependent packages' versions with [check_deps function|https://github.com/evernym/plenum/blob/master/plenum/common/pkg_util.py#L20] (we rely on pypi to install right version in the first place). We should check if use the function anywhere else, remove the function or maybe the whole file."
Answer: 870426.0

User story: "As of now we user virtualenv to run test on Windows 2016 (like on Windows 2012). It's because unlike Windows 10 Windows 2016 does not support linux docker images. Wait for the proper docker support on WIndows 2016 and update test pipelines to use docker for testing."
Answer: 870426.0

User story: "Currently existing ubuntu CI docker images can't be used on a Windows 10 machine because of UID arg. Find a workaround (maybe left it empty by default)"
Answer: 870426.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "As a Win64 user I need to have an MSI based installer for the sovrin node and all dependencies like 3d party python modules and orientdb.Research and choose right approach.PoA:* We can create a msi file of the sovrin node package pretty simple: https://docs.python.org/3/distutils/apiref.html#module-distutils.command.bdist_msiIn this case we have to create msi for each dependency because bundling is not supported.* As alternative, we can use tool like this https://www.firegiant.com/wix/tutorial/. The tool is not simple as python setup.py bdist_msi it may take time to learn how to work with it."
Answer: 870426.0

User story: "As a Win64 user I need to have an MSI based installer for the sovrin node and all dependencies like 3d party python modules and orientdb.PoA:* Write a script to create MSI for ledger, plenum, sovrin-common, stp, anoncreds, sovrin-node, sovrin-client* Integrate the script with Jenkins"
Answer: 870426.0

User story: Hyperledger security folks are recommending that we implement a number of best practices in our github management and our build process that lead to people having greater trust in the binary artifacts that we ultimately release. The formal spec for this body of best practices is located here:https://github.com/linuxfoundation/cii-best-practices-badgeI recommend that we analyze these best practices and create individual tickets for many or all of the items that we are not yet doing. This is not stuff required for minimal go live, but may have a bearing on whether we graduate from "incubator" to "full project" status in Hyperledger.
Answer: 870426.0

User story: "Process all TODOs in stp project"
Answer: 870426.0

User story: "Currently, the configuration file for validator nodes is stored in {{/usr/local/lib/python3.5/dist-packages/plenum/config.py}}. While this is technically Python, it really shouldn't be residing in this location. It is not obvious to anyone, nor does it follow any of the standard configuration file locations.On a Linux system, I would expect to find the configuration file in an {{etc/}} directory. I do know there is the possibility of creating another configuration file in {{.sovrin}}, but it's not clear which takes precedence.This does bring up the question of whether or not code-as-configuration is a good idea, but that's probably best served as a separate topic."
Answer: 870426.0

User story: "Currently it is possible to have a Trust Anchor add the same NYM as many times as they want without any message telling them that NYM already exists.This means that it will be possible for two individuals , if they are naming the seed to use to generate the key, to have the same NYM on the ledger.The creates a situation where you do not have a unique NYM."
Answer: 870426.0

User story: "The monitoring thresholds like Delta, Lambda, Omega need to be set after calibration. Currently we have set them arbitrarily after a little bit of observation[PoA | https://docs.google.com/document/d/12hLghQQVMk2s8H2ympKfVa234aYFrnQXNAjPWg4dM44/edit]"
Answer: 870426.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Given I am an Identity Owner, I should # be limited to updating my DDO files 3 times per day per DDO. # my DDO should not be hack-able. # All DDOs should be limited to a reasonable size (I'm not sure what that is, but when architects come to a decision, please update this requirement in the description)."
Answer: 870426.0

User story: "See rows 11,12 and 13 of https://docs.google.com/a/evernym.com/spreadsheets/d/1pf7XgCaKiiVMUJfsuwQ8TBrOvgSW0QNKhIDz9XfylBg/edit?usp=sharing"
Answer: 870426.0

User story: I need a tool that allows me to walk through records in the ledger, inspecting them in much the same way that MySQL Workbench would allow me to open a RDBMS, enumerate all the tables, write arbitrary queries, export data, and maybe repair something.This tool addresses multiple important use cases:# As a sysadmin or other technical community member, I need to be able to diagnose problems with corrupt data.# As an Evernym developer or tester, I need to be able to create corrupt ledgers and interact with them to test various failure scenarios. I also need to accept corrupt ledgers and diagnose what went wrong.#  As a Sovrin advocate, I want to be able to demo Sovrin's behavior with respect to the ledger, without having a UI that necessarily manifests a given feature.# As a developer in the Sovrin ecosystem, I want to be able to study the effects of my code on test ledgers.# As a sysadmin in an ultimate "nuclear failure" scenario where the world ledger is offline and no automated remediation seems possible, I might need to patch a corrupt ledger by following instructions issued by the TGB.I can imagine two different modes of operation for this explorer: one where it talks to a remote ledger via libsovrin, and one where it talks to a local data file.The tool should support all the ledgers used by sovrin (identity, voting, performance, pool, etc).The UI should run on any common desktop OS. It can be relatively primitive and inefficient, as long as it's easy to understand. We could do a SPA with react/node.js, like the one that [~<USER> wrote for the node admin UI, or we could use java or QT creator, maybe.
Answer: 870426.0

User story: "Given the Sovrin Validator nodes can recognize different types (roles) of transactions and which DIDs are signing transactions: # There should be a set of rules in the network (which the human Trustees & TGB would agree upon)# The rules should look for 3 variables: ## Who did the transaction? (DID)## What txn type is it?## How many of these txns do we allow per [time window]? e.g., how many nyms per hour?# Throttling txns based on their parameters can happen later in another story# If a txn violates the limits set in the config file: ## Reject the txn## We'll want to be able to warn the DID that they're getting close to their limit before shutting them down, but that will come in a later story.Whoever does the PoA should consult Nathan for getting it passed off."
Answer: 870426.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "The genesis txns will never change and any subsequent transactions will be added to the post-genesis txns file. The post genesis txn file will also be included with the source code."
Answer: 870426.0

User story: "When the client starts, it loads the genesis pool txns and then loads the post genesis pool transactions. The client should be able to verify multi-sig over txns in post genesis file"
Answer: 870426.0

User story: "Since source code can be different on different platforms the hash of the code and signature will differ too. The POOL_UPGRADE txns should indicate to which platforms the upgrade is targeted. This also helps in a scenario where we did not support platform *X* till version 9 but started supporting *X* in version 10, now when a node joins the pool which is on *X* does not need to do upgrades till version 9 but only for version 10"
Answer: 870426.0

User story: libSodium has functions like sodium_memzero(), sodium_mlock() having these functions and using them will help us further secure the memory allocations, it will also further mitigate the risk introduced by coredumps.On certain unix systems it will also use madvise() that advises the kernel not to include the locked memory in core dumps[See LibSodium Doc|https://download.libsodium.org/doc/helpers/memory_management.html]However NACL (python bindings over libSodium) the python library we use does not expose these libSodium functions.We need to first get these functions into NACL by some means or maybe have a small python bind of ourselves over libSodium and then use it in our code.This work requires someone who understands writing python bindings for "c" libraries. And also then python knowledge to be able to code it into STP
Answer: 870426.0

User story: "There are number of properties which do some initialization on first call and then return that cached value. To do it they use protected fields which are always in scope, but do nothing useful except of storing cached value.    We need decorator for this.  There is *functools.lru_cache* decorator which does memorization. If it is created with *maxsize=1* it does exactly what we need. But it is too resource consuming.     "
Answer: 871509.0

User story: "In the case that a transaction is sent to the validator pool via CLI or otherwise, and is unable to be posted to the ledger, all nodes in the pool should log the failure to post as an ERROR, including an explanation of why the ledger was unable to post the transaction.  For example, if consensus was not achieved, list the nodes that were able to participate, and which were not.    This posting may occur after a short timeout period, if necessary."
Answer: 878419.0

User story: "Update the Getting Started Guide to include all of the necessary DID/verkey changes and sovrin> changes where applicable.          Currently waiting on identification in other documents."
Answer: 890128.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "A Steward needs to have the ability to demote and promote their own node. The use case is if a Steward knows they will be down for maintenance and they want to remove their node from the pool so it does not count as a failed node during down time.    The current process of removing a node from the pool is to send the following command  {code}  send NODE dest=<NODE ID> data={'alias': '<node name>', 'services': []}  {code}    Currently only a Trustee has the permissions to perform this action.   To add promote the node back into the pool the Steward would need to be able to send the following command  {code}  send NODE dest=<NODE ID> data={'alias': '<node name>', 'services': ['VALIDATOR']}  {code}"
Answer: 900078.0

User story: "In the scope of message validation task messages were reimplemented as classes, but in a way to keep them compatible with a code that is written for named tuples.   That's why they mimic for being named tuples.    This works, but it is ugly and can cause problems like https://jira.hyperledger.org/browse/INDY-391"
Answer: 1180600.0

User story: "Implement backward compatibility mechanisms in    - client to node   - client to client     communications designed in https://jira.hyperledger.org/browse/INDY-242"
Answer: 1241443.0

User story: "We have multiple places where we call `ledger.getAllTxn()` and iterate through them.  It's very inefficient for a huge production ledger (especially domain one).    We need to make sure that we don't call getAllTxn() for Domain ledger.  It's also not good to call it for pool and config ledgers, but not as critical as for domain one.    [PoA|https://docs.google.com/document/d/1NYzrfhLmnvf9_sE2RMnyFI_WrEqHMMRW_vn1aIEl1dY/edit]"
Answer: 919067.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "daniel.hardman [10:37 AM]   What are we going to do about timestamps on the ledger? Should we go live without any timestamps? Should we write a consensus timestamp txn to the ledger once a minute?    <USER>[12:28 PM]   We have not decided about timestamps yet but a very basic implementation is for the primary to assign a timestamp to a batch of txns and non-primaries to accept the batch only if the timestamp is later than that of a previous batch and lies in a duration (+/- x minutes) around their time, this is how bitcoin does it. We are yet to come to a stage where the time is calculated on the basis of mean/median time or some std deviations away from it (edited)    daniel.hardman [12:36 PM]   That sounds quite reasonable. I don't think it's necessary to do anything super fancy yet, but I think we need at least minimal timestamp data on the ledger from the beginning of its history.    *Update:*  While implementing this consider what needs to be done when one node finds the timestamp from primary unacceptable? After it see sufficient PREPAREs, it should accept the PRE-PREPARE and take an action to fix its clock.  This process is not exactly like bitcoin, as in bitcoin nodes exchange timestamps when they connect to each other and the median value of those timestamps is part the calculation for validating timestamp of the next block"
Answer: 920277.0

User story: "Currently all migration scripts are applied in alphabetical order that satisfy the condition: (script's first version >= a version we're migrating from) and (script's second version <= a version we're migrating to).    This behavior needs to be enhanced. A shortest possible list of migration should be calculated and applied.   Example:   * We migrate from 1 to 10   * We have migrations 1_to_2, 2_to_4, 1_to_6, _8___to__9. Only 1_to_6 and 8_to_9 should be applied.    This task still requires some thinking on how to handle situations like this:   * We migrate from 1 to 10   * We have migrations 1_to_2, 2_to_4, 6_to_8, 1_to_7, 5_to_9"
Answer: 1250214.0

User story: "A node's ledger might get out of sync for different reasons (say, write to db failed), thus it will be lagging behind and will not be able to process newer PRE-PREPAREs, PREPAREs and COMMITs.      This needs to be fixed, we have CHECKPOINT in the code which is sent periodically, as of now it only helps in garbage collection. It should be used as opportunity to start a catch up process node come to a start where it can start processing new requests again.    Alternatively we can find specific places in the code where we discard messages, check for discard reason and start catch up if the reason is unsynced ledger.         [The design|https://docs.google.com/document/d/1OCUsD46HLhqhqZBJmn5wLZ2gTS1mcu6CQszoAh1gUA0/edit#heading=h.oqftj4wkhga5].         WARNING: If we bind to discards the protocol might get way too chatty. Discussion with Daniel and Jason is required!     "
Answer: 923016.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "For now keyring files are stored on disk and kept in memory without any encryption. This task created to discuss and implement logic of secure keyring data management."
Answer: 927878.0

User story: "Extend the response to the POOL_UPGRADE transactions with information how many nodes scheduled update, how many nodes wrote transaction to the ledger"
Answer: 929252.0

User story: We need to add some new functionality to the CLI so that we can test the transfer of an ID.     The suggested command would be "new key for ID xxxxxxx"    The scenario is that someone like a Trust Anchor creates an ID and puts it on the ledger without  a verification key. Now they want to give that ID to an owner and the owner needs to provide a verification key.   Today in the CLI with the way that wallets work you need to have the private key in the wallet of the new owner. The only way you can do that today is with the 'new key' command being run from the CLI on the target owners machine.   So in order for the target owner to take ownership of a key would be to generate that public private key pair on their machine.    To generate this new public and private key that is associated with the ID you would run 'new key for ID <identifier from Trust Anchor>' on from the target owners machine and then send the verkey to the Trust Anchor and have them run 'send NYM <ID> verkey=<the owners verkey>
Answer: 931703.0

User story: *Ledgers "stall" gracefully.* When a node is applying ledger txns to state, and runs into a ledger txn that causes an exception during deserialization or validation or processing, then the failure will be handled gracefully. A nice error message outlining the specific issue will be put to the log. That ledger will be set to a "STALLED" state. On startup, or on upgrade, or maybe even periodically, the node will reattempt to restart a stalled ledger, that is, process the ledger entry that failed. It will not proceed past the current state, and it will not participate in 3pc on any txns for that ledger. With this stalled concept, we don't need a separate consensus protocol for each ledger.    The combination of *Ledgers "stall" gracefully* and *Consensus may not be required* means we can recover from some nasty bugs.
Answer: 1241352.0

User story: *An upgrade is idempotent.* A txn to upgrade to version 5 should be allowed even if an earlier upgrade to v.5 has gone through. Given four nodes, if three are at v.5 and one is at v.4, then the one at v.4 will be upgraded. When it comes time for a particular node to upgrade, and it's already at v.5, it doesn't do anything.    <USER>[9:27 AM]   We partially have "An upgrade is idempotent", i say partially since node on upgrade can run an additional script, we need to ensure changes done as part of the script are idempotent, we need a test which before any pool upgrade is sent applies the upgrade twice on each node and verifies the update to be idempotent.
Answer: 933568.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "jlaw [7:53 AM]   *Nodes upgrade eagerly.* When a node is getting caught up, and it processes an upgrade txn, it should schedule it just like it normally would. If the date/time is in the past, then it upgrades immediately. Possibly a new story."
Answer: 1215164.0

User story: "The current process of releasing a Stable build once QA has tested it needs to be reviewed.    # Currently once QA has verified the build the QA lead goes into Jenkins and for each component in dependency order approves the build.  # Once QA has approved the component an email is sent to the product team.  # The product team would then go into Jenkins and do the same thing approving each component in dependency order.  # Once product has approved the build an email goes to the TGB group where someone else now runs through the same process. A TGB member goes into Jenkins and approves each component in dependency order.  # Now an email is sent to the Trustees  # A Trustee then goes into the CLI and send the POOL_UPGRADE transaction which is a large transaction that needs to be configured with the correct parameters."
Answer: 1216128.0

User story: Fix the ledger so a corrupt database record doesn't prevent the service from starting.    Success criteria for the ticket: either the service runs with a corrupted record (simply failing to retrieve that record with a graceful error) – or, if the database is too damaged to use, the service exits with a graceful error and says something like this to the log and the screen: "The database is corrupt. To fix the problem, delete the database and rebuild."
Answer: 1265917.0

User story: "Make components more independent to let them be easily updated or replaced.  For example election logic is coupled with view change logic.   Although there are inbox and outbox queues some communication is done by methods"
Answer: 1219738.0

User story: "If a pool contains a lot of nodes (20+) Trustee has to input a schedule for the POOL_UPGRADE txn.     А schedule for 4 nodes looks like:  {code:java}  {'Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv': '2017-06-07T21:00:00.258870+03:00', '8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb': '2017-06-07T21:05:00.258870+03:00', 'DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya':'2017-06-07T21:10:00.258870+03:00','4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA':'2017-06-07T21:15:00.258870+03:00'}  {code}  A schedule for 40 nodes will be huge.     "
Answer: 940517.0

User story: The CLI uses some terminology that is now stale. For example, what we used to call a "link invitation" is now a "connection request". A "keyring" is now a wallet. An "identifier" is now a "DID". A "link" is now a "connection".    We need to update the terminology to make it consistent with current thinking.     
Answer: 941217.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Attached are the genesis transaction files for the Alpha deployment of the network.  Please place them in the proper location in the repo so that they will be distributed with the new release.  Daniel said that you did a recent ticket that is related.  Ask Daniel if you need to know where."
Answer: 941670.0

User story: When dealing with keys of various types, which are really just large numbers, There are various ways to represent them to humans.  Sovrin seems to use them all - hexadecimal, base58, x85, etc.    These should be standardized, and a single representation should be used throughout Sovrin.    Example:  recently a note in the Alpha network was not communicating properly with other validators. The log message was this:    2017-06-13 15:00:14,025 | DEBUG | zstack.py ( 683) | handlePingPong | ev1 got ping from b'\{8pT}}%5v=qw0m>HUfdvJG<{/[zLO*P[s:$HKDZv'   2017-06-13 15:00:14,025 | DEBUG | zstack.py ( 788) | sendPingPong | ev1 will be sending in batch   2017-06-13 15:00:14,026 | WARNING | batched.py ( 103) | flushOutBoxes | ev1 rid b'\{8pT}}%5v=qw0m>HUfdvJG<{/[zLO*P[s:$HKDZv' has been removed   2017-06-13 15:00:14,026 | DEBUG | message_processor.py ( 29) | discard | ev1 discarding message deque([b'po']) because rid b'\{8pT}}%5v=qw0m>HUfdvJG<{/[zLO*P[s:$HKDZv' no longer available    This was difficult to debug since "b'\{8pT}}%5v=qw0m>HUfdvJG<{/[zLO*P[s:$HKDZv' " does not correspond to any recognizable entry in a transaction file.          *Acceptance criteria:*   * init_indy_node must output a public key and verification key in base58   * check that there are not other public places where we output non-base58
Answer: 941982.0

User story: "*Cases:*   * adding 10+ nodes   * network issues – connecting/disconnecting    * possible crash of significant part of the pool   * massive node demote / promote     All test should be performed in the same time with client's load.    The task requires a pool with 40 nodes.    *Steps:*    The Pool contains 15 nodes.    # Add 4 nodes (19 pool)   # Add 6 nodes (25 pool)   # Add 8 nodes (34 pool)   # Disconnect 10 nodes   # Connect 10 nodes after sometime   # Demote 10 nodes   # Promote 10 nodes               "
Answer: 942222.0

User story: "Right now, CLI requires a 32-byte cryptonym for many operations. We need it to prefer the 16-byte DIDs, and to discourage (deprecate?) the 32-byte versions."
Answer: 943160.0

User story: "It would be helpful to have ability to use sovrin-client in scripts. In particular, send multiple correlated commands and exit."
Answer: 950567.0

User story: Create a handful of scenarios that stewards can try. The items to choose from are located on the document called "Hardening Plan" under the section: "Key Use Cases that Should Work". Also decide on where these scenarios should "live" in order to point people to.  Three to five steps, approx 1/2 page each (ish)
Answer: 951912.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "This ticket is created by request. A minimum go live functionality summary document needs to be created. It is currently slated for approximately 6/7-6/12/17. Please finish the document and assign to <USER>for editing, so that it may be completed before 6/12/17.         The initial drafting is here: [https://docs.google.com/a/evernym.com/document/d/1tIzwhIUNTWaeNNWvkf085aqsSeOVQ2P6cNZ9UsrXTSs/edit?usp=sharing]     "
Answer: 952214.0

User story: "{quote}suppose a record in the database is corrupted (e.g., a sector of the disk is bad, so certain records cause a read failure). What happens to a running sovrin-node process that attempts to read from that part of the database?  {quote}       See 3.a [https://docs.google.com/document/d/1ae6Ud64gUjl-YC3ADDU5KuW_A-kPS9l9g6FGJCylFCs/edit]          "
Answer: 953896.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "     The 'NotImplementedError' exceptions:    [https://github.com/sovrin-foundation/sovrin-client/blob/fa01e3eabcfcad88c54bfe51158c3de77659b600/sovrin_client/client/wallet/attribute.py#L74]         The tests which skipped by this issue:   * testSendAttribSucceedsForHexHash   * testSendAttribFailsForBase58Hash   * testSendAttribFailsForBase64Hash   * testSendAttribSucceedsForHexEnc   * testSendAttribFailsForBase58Enc   * testSendAttribFailsForBase64Enc   * testSendAttribHasInvalidSyntaxIfRawAndHashPassedAtSameTime   * testSendAttribHasInvalidSyntaxIfRawAndEncPassedAtSameTime   * testSendAttribHasInvalidSyntaxIfRawHashAndEncPassedAtSameTime   * testSendAttribHasInvalidSyntaxIfUnknownParameterIsPassed"
Answer: 960868.0

User story: "See sovrin_common/types.py"
Answer: 961104.0

User story: "# We should have a file extension on each file.   # We should zero pad the files so the ordering is easier to deal with 000001, 000002, 000003 and so on.   # Having all the files in one directory can also be an issue. We need to think about how this will look in 20 years of running. We should break up the files into sub-directories. Determining how many files to have in a given directory will also help determine how many digits to use in zero padding the files."
Answer: 962382.0

User story: "A node's ledger might get out of sync for different reasons (say, write to db failed), thus it will be lagging behind and will not be able to process newer PRE-PREPAREs, PREPAREs and COMMITs.      This needs to be fixed, we have CHECKPOINT in the code which is sent periodically, as of now it only helps in garbage collection. It should be used as opportunity to start a catch up process node come to a start where it can start processing new requests again.    Alternatively we can find specific places in the code where we discard messages, check for discard reason and start catch up if the reason is unsynced ledger.         WARNING: If we bind to discards the protocol might get way too chatty. Discussion with Daniel and Jason is required!"
Answer: 963523.0