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: *Story*  As a user of an Indy network that enforces a transaction author agreement, I do not want my agreement acceptance time to be recorded with my transactions as it is specific enough that it could allow correlation across my various DIDs and payment addresses.    *Acceptance Criteria*  * When an agreement is anchored to the ledger, only the date needs to be recorded.  * When a transaction is written to the ledger, only the date of the agreement acceptance should be recorded on the ledger as part of the transaction.  * If the signed transaction includes too much precision in the timestamp, the transaction should be rejected with the error: "TAA timestamp is too precise and is a privacy risk."  * Validation of agreement acceptance should accept any transaction with the same acceptance date as the current agreement was posted to the ledger, or newer.  * If the timestamp when the author agreement was anchored to the ledger is within two minutes of zero UTC, then future transactions with a user agreement acceptance date of the previous day will also be accepted to account for potential clock skew.    *Note*  * The format of the transaction on the ledger does not need to change from a datetime, we will just ignore the timestamp portion of the datatype.
Answer: 24093.0

User story: "* As a Network Admin, I would like to use GET_AUTH_RULE output as an input for AUTH_RULE, so that I don't need to do additional re-formatting.   * I need to use it in 2 cases:   ** GET_AUTH_RULE(specific rule) -> AUTH_RULE (set specific rule)   ** GET_AUTH_RULE(all rules) -> AUTH_RULES (set all rules)\    *Acceptance criteria*   * Modify GET_AUTH_RULE output to match AUTH_RULE input   * Fix tests   * Add tests to check that GET_AUTH_RULE outputs can be used as AUTH_RULE input for 2 cases above"
Answer: 4555.0

User story: "As a Trustee(s), I need to have a way to set multiple AUTH_RULES by one command, so that it's easier for adding/changing auth rules and requires less communication with the Ledger.    *Acceptance criteria*   * Define the command format to add/edit multiple auth rules (from 1 to all)   * The auth rules override previous ones   * Cover by tests"
Answer: 33319.0

User story: "*Acceptance Criteria*   * Support an Auth Constraint that forbids an action   * Apply this to Schema editing   * Cover by tests"
Answer: 63101.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 of now, we have AUTH_RULE txn that can set/modify one AUTH_RULE.    However, there are cases (such as initial bootstrap), when we need to set multiple (or even all) auth rules.    In order to simplify and improve usability, especially in the case of multi-signature, we need to have a command to set multiple auth rules.    Option:   # Modify existing AUTH_RULE command so that it supports a list of rules to be set   ** Pros:   *** Easier and more consistent   # Creates a new AUTH_RULES command to set multiple rules   ** Pros   *** More granular in terms of auth rule permissions for AUTH_RULE/AUTH_RULES, so that we may potentially have different policies on who can change each rule."
Answer: 1869.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: "*Story*  As a transaction author, I need my transactions to be written to the ledger preserving me as the author without my needing to accept the responsibilities of an endorser so that I can focus on my business. Instead, I will have a business relationship with an endorser who will endorse my transactions.    *Goals*  * It is easy to tell from the ledger who is the endorser and who is the transaction author for each transaction.  * A transaction author can use a different transaction endorser for future transactions, including updates to attribs and key rotations.  * The transaction must use the author key to sign the transaction author agreement regardless of whether an endorser signature is also needed.  * If the endorser field is included in a transaction, then the ledger will reject the transaction if it is not signed by the endorser.    *Acceptance Criteria*  * Analyze the work required.  * Raise issues for completing the work.    *Notes*  * The transaction author field is intended to be used for all future permissions.  * The endorser field only needs to be recorded in order to:  ** Allow auditability, that the transaction was written with correct permissions  ** Allow the network administrator to bill the endorser for the write  * Sub-endorsers or chains of endorsers would be desirable for a global network, but are not required at this time. We recognize that in the future adding multiple levels of endorsers or delegated endorsers could be a breaking change.  ** Endorsers could be a list, but it would still require the transaction author to know all endorsers at the time the transaction is created. That list could be built off-ledger by sharing a draft transaction.  * Suggested user flow:  ** Transaction author identifies the need for creating a transaction  ** Transaction author identifies which endorser they want to use  ** Transaction author includes the DID of the endorser in the transaction, and signs the transaction.  ** Transaction author passes the signed transaction to the endorser  ** Endorser adds their signature  ** Endorser submits the multi-signed transaction to the ledger  ** If the endorser will not accept the transaction, and the transaction author wants to try a different endorser, the transaction author must recreate the transaction in order to include the new endorser DID.  * This process is separate from a potential process by which payment could be attached to a third party transaction so as to allow it to be written to the ledger. That potential feature of the Sovrin Network is being tracked in [ST-608|https://sovrin.atlassian.net/browse/ST-608]. In other words, transaction endorsers and authors don't need to be tracked separately for Sovrin XFER transactions."
Answer: 226127.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 release versions of indy-node looks like semver but actually doesn't follow it having build numbers as patch part of the version.     Requirements:   * 3rd number of the version should have a real patch meaning (follow semver)   * versions of different branches of the code should be clearly related   * indy-node should be easily linked to indy-plenum version for both dev and stable code   * there should be clear relation between artifacts and code"
Answer: 70969.0

User story: "Currently it's not possible to promote any existing DID which doesn't have any role (e.g. created without it or demoted before).    Need to decide whether it's worth to have and design the rules. "
Answer: 84177.0

User story: "For now TRUST_ANCHOR can't revoke themselves."
Answer: 366949.0

User story: *Story*  As a systems administrator responsible for solutions built on top of an Indy network, I want to be able to monitor the health of the network to ensure that my solutions will be reliable.    As a steward, I want to be able to setup network maintenance without having to use my steward keys in a dangerous manner.    Notes:  * This user is not a steward on the network.  * It is reasonable to require that this user has a trusted position on the network.  * This user is very technical and motivated to build a monitoring system.  * The monitoring system requires:  ** The information returned by validator-info across the various stewards, but today this information is only available to users with a steward role.  ** Other information that can be provided by querying the ledger. This does not require any changes.    *Acceptance Criteria*  * A non-steward role exists by which a trusted administrator can access validator-info across all stewards in a consensus pool.  * This role is called "Network Monitor".  * The only permissions this role has beyond an unprivileged user is to access validator-info.  * A user can be assigned this role by a steward (no multi-signature necessary).
Answer: 146932.0

User story: "This story is an outcome of https://jira.hyperledger.org/browse/IS-1102  We should limit our number of attributes in schema to 125 to make cred def pass the request limit check.    *Acceptance Criteria*  * Clearly document the limit  * Implement a check for the limit  * Test that a transaction with 125 attributes with names of the maximum length will succeed  * Test that a transaction with 126 attributes will fail    Excluded:  * The performance of a transaction with 125 attributes does not need to be tested with this story"
Answer: 151701.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: [In the Steward Getting Started Guide|https://docs.google.com/document/d/1AH618bj4q9U8FS1uyoIgbcvwNzaghBCQ1v44tNpZ2OU/edit#heading=h.votw8a9lan5j]    Shows that the verkey will come out looking something like this:  {quote}{{bfede8c4581f03d16eb053450d103477c6e840e5682adc67dc948a177ab8bc9b}}  {quote}  Which to the best of my knowledge is a hexlified version of the verkey.  Later on, [in the guide|https://docs.google.com/document/d/1AH618bj4q9U8FS1uyoIgbcvwNzaghBCQ1v44tNpZ2OU/edit#heading=h.eg8r1qxkvix7], to send the the client to add the Steward's node to the ledger, they must execute:  {quote}python3 -c "from plenum.common.test_network_setup import TestNetworkSetup; print(TestNetworkSetup.getNymFromVerkey(str.encode('bfede8c4581f03d16eb053450d103477c6e840e5682adc67dc948a177ab8bc9b')))"  {quote}  If they send the hex version of their verkey, the transaction would be rejected.    I've been able to produce the Base 58 version of the verkey in Node.js with just a simple Base 58 library, decoding the hex verkey into a string and then encoding it with the library.    This way when the user gets to this step:  {quote}indy> ledger node target=<validator_verkey_in_Base58> node_ip=<validator_node_ip_address> node_port=<node_port> client_ip=<validator_client_ip_address> client_port=<client_port> alias=<validator_alias> services=VALIDATOR blskey=<validator_bls_key> blskey_pop=<validator_bls_key_pop>  {quote}  They then use this base58 key they obtained above.    Can we make it so that the base58-encrypted key comes out when you run init_indy_node?          
Answer: 205790.0

User story: "tomdavidson commented on Sep 9, 2016  @jasonalaw Thank you for the presentation and discussion at BYU OIT today.    Using Plenum/ledger outside of Sovrin might accomplish some of your outreach goals. For example, I'm after a distributed, append only, and ordered, object repository (avoiding rdbms) to use as an event store. More docs would be nice, esspeically comparted to the some of the hyperledger project's docs."
Answer: 496352.0

User story: "h3. *[nathanawmk|https://github.com/nathanawmk]* commented [on Aug 9|https://github.com/hyperledger/indy-plenum/issues/865#issue-349091902]    I am looking to setup up and deploying a decentralized identity platform on a global scale and I am looking to indy. Has anyone setup indy for global scale?"
Answer: 496410.0

User story: "Currently creation of different groups in the same tagged namespace leads to creation of different inventory dirs. Having one inventory dir per namespace would be highly preferable."
Answer: 222361.0

User story: "Currently pool automation scripts can provision only on-demand AWS EC2 instances. It might be much cheaper to utilize spot instances as well (instead)."
Answer: 222389.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 tests are performed using molecule and its vagrant driver only. It makes sense to have docker based way as a default to speed up development since docker containers are much lighter than vagrant VMs. Also it might be useful for future integration into CI pipelines.    Acceptance criteria:   * tests can be run on docker containers as a default scenario   * tests are passed"
Answer: 225182.0

User story: *Story*  As an organization issuing claims on an Indy network, I want to be able to delegate the issuing of credentials to a third party so that I benefit from them simplifying my business processes. Verifiers of those credentials should see that they came from me as the controller, but should also be able to identify the processor for audit purposes.    *Requirements*  * The controller should be able to change processors by updating the credential definition, but the history of processors should be retained.    *Acceptance Criteria*  * Create a plan  * Get architectural review of the plan from stakeholders including Evernym and the Sovrin Foundation  * Create the necessary issues    *Possible Approaches*    _Add issuer field to cred def transactions_  When using delegation, where one company (the processor) issues credentials for another (the controller), to the verifier the claims appear to have come from the controller.  This is fine, but we also need to be able to tell that the processor was involved with issuing the claim.     To do this, please add an additional field to cred def transactions called "issuer".  The value of the field will be a DID that will be set by the controller before it is written to the ledger.    In addition it will be necessary for the verifier to be able to determine what cred def was used to make the claim in the proof. In the current proof format, the schema sequence number is provided for each claim, but the cred def sequence number is not. Other than parsing the ledger to find the cred def with a particular "ref" and "identifier", which would be very inefficient, there is not an apparent way for the verifier to find the correct cred def. If indeed there currently is no better way, then please also add a cred def sequence number to the claims in a proof.    It will then be the responsibility of the verifier to retrieve the cred def from the ledger to determine the processor, when needed. Two very key customers currently need this capability, with more to follow.    The additional field in the cred def allows the controller to show that he has delegated proof issuance to the processor who actually holds the private keys to the cred def.    *Notes*  This story introduces a new participant in credential verification. The 3-party story (issuer, prover, and verifier) is modified into a 4-party story, where the issuer is split into 2, the controller and the processor. Both will need DIDs on the network, so that the verifier is able to see that the credential is from the controller, by means of the processor.
Answer: 273623.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: "*Story*  As a trustee of an Indy Network, the network should require other trustees to sign administrative transactions I want to sponsor so that I am confident that no single trustee can abuse the network.    *Acceptance Criteria*  * All transactions that require a trustee role should require multiple trustee signatures. Specifically:  ** Add a trustee  ** Remove a trustee  ** Add a steward  ** Revoke the role of steward  ** Demote a consensus node  ** Send an upgrade transaction to the ledger  * The number of signatures required should be specified on the configuration ledger  * Create a Plan of Attack for how we would address this problem.  * Create a HIPE describing how we want to handle trustee permissions.  * Create an Epic and issues for doing the work.    *Notes*  * In the future, it would be useful to specify the number of signatures as a ratio of total trustees, but this is not required for this story. (Depends on INDY-1594)"
Answer: 283565.0

User story: "This is closely coupled with INDY-1622."
Answer: 316019.0

User story: "*Acceptance criteria*  * _inventory_init.py_ script should prepare group vars file where number of node and client instances are separately configurable  * _pool_create.yml_ playbook should provision both node and client instance according to inventory group vars  * _pool_install.yml_ playbook should configure both node and client instances according to inventory group vars  * client instances should have load script installed as well as pool genesis transaction pointing at nodes  * _pool_destroy.yml_ playbook should destroy both node and client instances  * _pool_*.yml_ playbooks probably should be renamed to better reflect that they manage not only nodes, but clients also (probably just _create.yml_, _configure.yml_, _destroy.yml_)"
Answer: 316031.0

User story: "Additional requirements:  - groups should be named  - instances of group should be created in different AWS regions  - there should be easy way to generate ssh config to access instances in pool  - there should be easy way to access all instances in group as a whole using Ansible    There are two major options how this can be implemented:  1. Tool that creates pool should outputs ssh config and ansible inventory file that could be used to access group instances without requiring access to AWS API.  2. Tool that creates pool just tags instances somehow, so Ansible dynamic or in-memory inventory could be used, which can be easier for further automation.  "
Answer: 316041.0

User story: "Each Steward must send a NODE txn with Proof of Possession of his BLS keys. So, we need a script that can help in generating the transaction.    *Acceptance criteria*   * Create a script in Indy-node: `generate_bls_proof_of_posession`     ** the script need to be installed with Indy Node   ** Input for the script: no   ** Output:   *** BLS Public key in a form to be sent in NODE txn (base58-encoded)   *** BLS Proof of possession for the Public Key in a form to be sent in NODE txn (base58-encoded)"
Answer: 327579.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: "We need several aligned graphs:    1. Throughput  - client_stack_messages_processed_per_sec  - master_ordered_requests_count_per_sec    2. Latency  - avg_master_monitor_avg_latency  - avg_monitor_avg_latency    3. Queues  - avg_node_stack_messages_processed  - avg_client_stack_messages_processed    4. Looper (Y log scale)  - AVG_NODE_PROD_TIME  - AVG_SERVICE_REPLICAS_TIME  - AVG_SERVICE_NODE_MSGS_TIME  - AVG_SERVICE_CLIENT_MSGS_TIME  - AVG_SERVICE_ACTIONS_TIME  - AVG_SERVICE_VIEW_CHANGER_TIME  "
Answer: 334416.0

User story: "*Story*  As a user of an Indy network that does not require fees for writes, I want my writes to the global ledger to be sponsored by a trust anchor who prevents spam, but I want to retain future control of my writes so that I can modify my writes or work with a different trust anchor in the future.    *Acceptance Criteria*  * Create a plan for effectively using trust anchors to sponsor writes to the ledger  * Get architectural review of the plan  * Create the necessary issues    Goals:  * A trust anchor can write a cred def that is owned by a third party  * The owner can modify that cred def  * A trust anchor can write a schema def that is owned by a third party  * The owner can modify that schema def"
Answer: 335643.0

User story: "There are some requirements for each Node in the pool (hardware, configuration, networking).  We need to make sure that every Steward has correct configuration and all Nodes participate in consensus.    *Acceptance criteria:*    We need to check the following for every Node and Steward in the live pool:   * Hardware and min amount of RAM   * Correct configuration of separate NICs including whitelisting and routing   * Firewall settings to limit max number of clients   * Correct BLS keys   * Participates in consensus (on writing data)"
Answer: 490339.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: *Story*   As a trustee of a network that has implemented a payment system, I want to use that payment system to manage writes (in particular credential definitions and schemas) to the ledger instead of requiring the use of trust anchors.    *Acceptance Criteria*   * Create a configuration setting: "writes-require-trust-anchor", default to True   * When the configuration is false, all users have permission to write to the ledger.   * When the configuration is true, the Trust Anchor role is required to write.   * The permission should affect all write transactions.  * Permissions should continue to enforce that only owners of existing transactions can edit them (no change to this behavior).  * The Trust Anchor role should continue to exist in case it is needed in the future.    *Notes*   * Payment of fees during a write is enforced by plugins, and not part of the core ledger.   * The work to make this configuration flexible across all permissions is being tracked in INDY-1527.   * We assume that all nodes in a network set this property consistently. If n-f Stewards set this flag to not require TrustAnchor role, then it will not be required the same as with other consensus driven configuration.  * We decided against only removing the need for the Trust Anchor role for credential definitions and schema definitions, but still requiring it for writing nyms.  ** Requiring a Trust Anchor in order to writing a nym transaction would help us to ensure that best practices are being used--personal data is not being written to the ledger (GDPR compliance).  ** We decided that it is premature to enforce best practices regarding nyms early in the life of the ledger. We should wait to see our recommendations proved in practice before adopting inflexible policies.  ** We decided that we should wait until users of Indy have created formal policies for on-boarding Trust Anchors.  
Answer: 354532.0

User story: "*Story*  As a trustee responsible for an Indy Node network, I want to be able to update ledger permissions so that I can implement my governance rules specific to my network.    *Acceptance Criteria*  The ledger permissions available to each role should be configurable without code changes.    *Notes*  * The list of ledger roles and the list of permissions do not need to be configurable, but the mapping between them should be configurable.  * The current ledger roles and permissions should remain the same."
Answer: 354562.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: "*Acceptance Criteria*  A document exists in the Indy Node documentation folder that describes the architecture and goals of the current update system.    Key items to document:  * The system pushes updates out simultaneously to all nodes on the network.  * This allows Indy Node to be upgraded in unison, and avoids the need for backwards compatibility.  * Which ledger the upgrade transaction uses.  * That the upgrade transaction defines an arbitrary package so that systems building on top of Indy Node can install their own plugins. (INDY-1499)  * That Indy Node control tool updates that package using a system appropriate to the specific platform: currently Debian, but could be RedHat or Windows"
Answer: 642933.0

User story: "*Story*  As an administrator of a node on an Indy Network, I want the upgrade transaction to specify my network specific package rather than generic Indy Node so that my network specific package can perform configuration and customization functions such as installing network specific plugins to the Plenum Ledger.    *Acceptance Criteria*  * The Node upgrade script should use that value to call the platform specific package manager (on Debian will be apt) to install or update the package.    Enhance node_control_tool to update the specified package, not IndyNode (see https://github.com/hyperledger/indy-node/blob/master/indy_node/utils/node_control_tool.py and https://github.com/hyperledger/indy-node/blob/master/scripts/upgrade_indy_node_ubuntu1604.sh)    *Notes*  * The work to have the upgrade transaction include a value containing the package that should be upgraded is in INDY-1499  * The Sovrin network wants their network upgrades to call the Sovrin package instead of Indy Node. The Sovrin package depends on Indy Node.  * There will be a new release of the Sovrin network package with each release of Indy Node."
Answer: 364304.0

User story: "*Story*  As an administrator of a node on an Indy Network, I want the upgrade transaction to specify my network specific package rather than generic Indy Node so that my network specific package can perform configuration and customization functions such as installing network specific plugins to the Plenum Ledger.    *Acceptance Criteria*  * The upgrade transaction should include a value containing the package that should be upgraded.    Add a new (optional) parameter to POOL_UPGRADE txn with a package name. As of now this is IndyNode, and it should remain the default. https://github.com/hyperledger/indy-node/blob/master/docs/transactions.md#pool_upgrade    *Notes*  * The work for the Node upgrade script should use that value to call the platform specific package manager to install or update the package is tracked in INDY-1500.  * The Sovrin network wants their network upgrades to call the Sovrin package instead of Indy Node. The Sovrin package depends on Indy Node.  * There will be a new release of the Sovrin network package with each release of Indy Node.  "
Answer: 364350.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 of now POOL_UPGRADE txn upgrades IndyNode only with the dependencies.   We need to be able to use the txn to upgrade the products based on IndyNode.    See a PoA in [https://docs.google.com/document/d/1_sVPtltsTZqP1ZK_wimrJuY8-Emc89TwYT51m0OZxF4/edit#heading=h.z1u0dzf62loi:]   * Extend the POOL_UPGRADE txn with the (optional) package name (assume indy-node if not present)   * get the list of dependencies for the specified package (apt-cache can be used on Ubuntu)     * If it sees indy-node there, it get the list of dependencies for indy-node as well (use existing logic).     * As an output, it creates a list of the packages with dependencies to be installed in the correct order.  For example,  [indy-plenum=1.4.4, indy-node=1.4.1, plugin1=1.0.1, plugin2=1.0.2, specified_package=2.0.0]"
Answer: 367581.0

User story: "*Story*  As a developer fixing issues with Indy Node, I want to understand the performance impact of running the recording tool so that I can deploy the recorder in situations where it will be helpful and not prevent my addressing issues.    *Acceptance Criteria*  * Reproduce the test in INDY-1343 with the recorder running, and compare the results with what we saw without the recorder running."
Answer: 369084.0

User story: "*Story*  As an administrator of a node on an Indy network, I want an automatic process for new client connections to be accepted by the network.    *Acceptance Criteria*  Implement the solution designed in INDY-1418."
Answer: 409309.0

User story: "*Story*  As an administrator of a node on an Indy network, I want an automatic process for new client connections to be accepted by the network.    *Acceptance Criteria*  Design a process by which new client connections can be accepted even when there are a lot of connections on the existing external NIC. The process must not require manual intervention.    The process may happen on a periodic basis.    *Notes*  Potential approaches:  * Force ZeroMQ to close connections on a timeout  * An external process such as a firewall monitors the length of open connections and kills them on a timeout  * * When the connection buffer becomes full, clear the connection buffer and force legitimate clients to reconnect  "
Answer: 409311.0

User story: *Story*    As an administrator of an Indy node, I want log messages to be clear and well written.    *Acceptance Criteria*    Log messages that have been reviewed by Product Management and the Operations Team should be incorporated into the product.    Log messages and levels in the product should match the Revised Message and Revised Level in the spreadsheet. If the revised level is "None" then the log message is unnecessary. Blank revisions means that no changes are needed.    If there is a "Revised Message" but the "Current Message" is empty, then the log messages is new and should be added to the product.
Answer: 409344.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: "*Acceptance criteria*   * Create a new command GET_VALIDATOR_STATUS   * Create a new role `observer` to be able to send this command (so that not everyone can do it, but it's not necessary to be a Steward)    * a NYM with a `observer` role can be created by Trustees and Stewards   * The reply should be quite similar to GET_VALIDATOR_INFO one, but should not contain information about machines running the code."
Answer: 707094.0

User story: We already log if a request wasn't ordered in 1 minute specifying the nodes that didn't participate in consensus.    We need to log what nodes didn't participate even for ordered requests so that we can detect what nodes may have problems         *Acceptance criteria*   * If a node didn't participate in ordering of N sequential requests (that is no PREPAREs nor COMMITs received from the node), we need to log a warning: "Node X didn't participate in ordering of N requests"
Answer: 706068.0

User story: "Main problem with processing logs is that it's very long CPU-bound (and sometimes memory-bound) task. Also, downloading logs from pool to process them locally takes a lot of time.    If we could run log processor on large 25-nodes test pool directly we:  - effectively get 50 cores and 200 Gb of RAM to process logs, which is much more than any desktop have  - can get results before downloading all logs, which takes time    In order to do this we need:  - remove dependency on matplotlib from log processor  - create ansible playbook to upload log processor and its config to pool, run it in pool and then download results"
Answer: 718686.0

User story: "As of now only one CLAIM_DEF can be created for the same Schema, DID (creator) and Signature Type.    We need to introduce a `tag` field which can be used to distinguish CLAIM_DEFs for the same Schema/DID/Type.    See the proposed format here: [https://github.com/hyperledger/indy-node/blob/master/docs/requests-new.md#claim_def]    See the design for anoncreds txns (including CLAIM_DEF) here: https://github.com/hyperledger/indy-node/blob/master/design/anoncreds.md"
Answer: 437050.0

User story: "Things to do:  1. Install pool of 25 nodes *for each master/stable build of indy-node package* in CI/CD infrastructure.  2. Run post-install tests (https://github.com/hyperledger/indy-post-install-automation) against this pool in scope of CI/CD pipeline.  3. Send pytest results produced by this tests to QA team via mail.    [~<USER> [~<USER> Can we estimate effort for this task and plan it to some sprint?"
Answer: 728765.0

User story: "*Story*  As an administrator of an Indy node, I want to understand who my node thinks is the primary node on a daily basis so that I can identify network problems.    *Acceptance Criteria*  * A log message of level INFO should be printed each day.  * The message should read: This node thinks [node identifier] is the primary."
Answer: 768224.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: "*Story*   As a consumer of Indy, I want to the documentation to be easy to find and easy to use so that I can quickly get my questions answered and deploy a node.    *Acceptance Criteria*   * Documentation exists within the /docs/ folder of the Indy source code repository.   * Documentation should be divided based on the target audience: contributors to Indy vs consumers of Indy.   * Documentation meant for consumers of Indy should be published to ReadTheDocs.io.    *Notes*   * Advantages to using ReadTheDocs.io:   ** It is consistent with other Hyperledger projects.   ** It is easier to find via Google than documentation only contained in GitHub.   * Documentation in ReadTheDocs must be in RST format. Converters exist from MarkDown to RST.   * See the Docs guidance provided by the Fabric project:   [https://github.com/hyperledger/fabric/tree/release-1.1/docs]"
Answer: 768923.0

User story: "We found some issues with existing View Change.  We need to implement it in a proper way as defined in PBFT: https://www.microsoft.com/en-us/research/wp-content/uploads/2017/01/thesis-mcastro.pdf.    See details in https://jira.hyperledger.org/browse/INDY-1080    Please take the following requirements into consideration:  * We need to take into account RBFT and 3PC batching specific  * Have a look at the Fabric's PBFT experience and Sawtooth's RBFT one: INDY-1290  * The new View Change must be a pluggable strategy   * State machine needs to be used  * PBFT viewchange is more conservative. So this could be more succeptible to follow-the-leader DDOS attacks. We need to take this into account  * We need to have a suite of aggressive real-world simulation tests where we hammer the protocol such that we can quickly be confident we've improved without deploying.  * We need to prove that the new implementation is better by executing the tests written in the scope of INDY-1296"
Answer: 490008.0

User story: "We already have some ways and plugins for notification (email notifications, SQS, etc.)    Currently we have a feature to notify Stewards about Suspicious Spikes (by email): INDY-1251.    We need to send more notifications to Stewards:   * View Change start   * View change end   * Catchup start   * Catchup end   * Blacklisting a Node   * Blacklisting a Client   * Suspicious Primary   * Performance degradation (InstanceChange)   * Upgrade start/end   * other severe errors and warnings"
Answer: 779151.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: "*Story*  As an administrator of a deployment of Indy Node, I want failed transactions due to lack of consensus to produce a log message alerting me to the fact the transaction failed so that I can troubleshoot the situation.    *Acceptance Criteria*  * If a node receives a request to write a transaction, and does not achieve consensus within the timeout period, then issue a log message with the level ERROR.  * The timeout period should be configurable, and default to 60 seconds.  * The log message should say:    {noformat}     Consensus for ReqId: [] was not achieved within [Timeout] seconds:     Primary node is [Node ID]     Received Pre-Prepare from [node_id]     Received [N] Prepares from [nodes_id1, node_id2, ...]     Received [M] Commits from [nodes_id1, node_id2, ...]     Transaction contents: [Contents]    {noformat}    *Notes*  * The work on [INDY-465|https://jira.hyperledger.org/browse/INDY-465] demonstrated that some transactions don't fail due to an error on the node, but due to some other problem with the network. The only symptom the node sees is that the transaction is not recorded to the ledger.  * We could send a keepalive to sender, but there are concerns that would be exploitable for denial of service."
Answer: 500128.0

User story: *Story*    As a Product Manager of Indy Node, I need a list of all the log messages so that I can review them holistically.    *Acceptance Criteria*    Produce a spreadsheet containing all the logging strings from Indy. It will have the columns:  * "Current Message"  * "Log Level"    We will add columns for "Revised Message", "Revised Level".    A member of the development team will review the messages and include proposed revisions.  * Reviewer can suggest a Revised Message or Revised Level, can mark level as "None" if the log message is unnecessary, or leave Revised Message and Revised Level blank if no changes are needed.  * If there is a "Revised Message" but the "Current Message" is empty, then the log messages is new and should be added to the product.    The spreadsheet should be delivered to Product Management and a representative of the Operations Team to review the strings.
Answer: 505846.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: "*Story*  As an administrator of an Indy Node, I want to understand policies around firewall usage to minimize network risk to DDoS attacks.    *Acceptance Criteria*  * Administrator documentation exists for configuring IPTables on Linux as a firewall protecting both node network inferfaces  * The documentation explains how to specifically protect the NIC used for communication between network nodes, restricting communication to whitelisted addresses.  * The documentation explains how to quickly blacklist an IP address on either NIC.    *Notes*  * We estimate that half of the stewards on the Sovrin network use IPTables as their firewall.  * The stewards that do not use IPTables appear to use a range of commercial firewall packages, and be educated in their use to conform with network steward guidelines. Therefore, examples with IPTables are sufficient to guide these admins.  * We evaluated other tools as firewall proxy, and decided not to include them in the recommendations at this time:  ** An HTTP proxy such as Nginx could be used to meet this use case  *** [https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/.|https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/]  *** This introduces additional complexity, is not the core use case of Nginx, and does not appear to be needed at this time.  ** A tool such as fail2ban can automatically scan a log file and update firewall rules.  *** [https://www.fail2ban.org/wiki/index.php/Main_Page]  *** Steward administrators might choose to run fail2ban, but it won't be required at this time so we do not need to document it.  * This documentation does not need to account for Observer Rings, but can be adapted for that use case when they are part of the network.  * The documentation needs to comply with the Sovrin Network guidelines for stewards:  ** As the first implementation of an Indy network, the Sovrin Network Guidelines are a useful guide for how our tool should work.  ** Mandates usage of two NICs, (INDY-1249, INDY-1282)  ** Mandates usage of a firewall,  ** Provides specific targets for how long it should take for an IP address to be blacklisted or whitelisted."
Answer: 526065.0

User story: "Stewards must notice within 15 minutes that there was a sudden spike in traffic, and contacted Sovrin support.         We already have a functionality to detect Spikes (see `SpikeEventsEnabled`) and be able to send emails.    We need to   * make sure that it works properly   * make sure that it notifies Stewards properly   * have detailed instructions how to configure it for Stewards   * make sure that this is configured on all Nodes in the Live Pool."
Answer: 526277.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: "We do have at least one requirement related to DDoS that we really need to address, which is that we need to be able to bind listeners in indy-node to a specific NIC. (I am told that, although we can declare in config that we’re binding to a specific NIC, logs reveal that we always bind to all NICs. This may be inaccurate, but if it is, we should teach people how to do it right, because apparently nobody is.) The reason I feel like this is urgent is that a major DDoS mitigation strategy for MGL was the requirement that all validators should have 2 NICs--one dedicated to consensus with other validators, and one dedicated to clients. If we have bad clients doing DDoS, but we have two NICs, then we shouldn’t be able to defeat consensus on the other NIC.        We need to make sure that we support using two separate NICs and provide detailed instructions on how it can be achieved.    We should explore working capacity of 2 NIC node configuration before we will configure persistent pool this way because now both node and client IPs bind to 0.0.0.0.    - Will node work with 2 NIC and different IPs for node and client in pool ledger?  - Will pool work with 1 / f+1 / n-f / n nodes configured this way?"
Answer: 527706.0

User story: "The implementation based on the Design from INDY-1177"
Answer: 529171.0

User story: "We need to support GET_VALIDATOR_INFO request in libindy and CLI"
Answer: 547584.0

User story: "Taken into account our agreement about refactoring with breaking changes, I believe we have a good time for migration from LevelDB to RocksDB because of the following:   # Migration to RocksDB requires migration (modification) of the ledger. We are going to migrate the ledger in any case (hopefully the last time) for refactoring, so we can combine it with RocksDB support, so no more migrations are needed in future.   # I thing migration to RocksDB should not take much time, since Dmitry did a PoC, and everything worked. We just need to merge the old branch [rocksdb-integration|https://github.com/hyperledger/indy-plenum/tree/rocksdb-integration].   # We have new resources for this work.   # It will fix bugs like INDY-1182, since it's possible to access RocksDB from other process in read only mode (it's not possible for Leveldb, that's why read_ledger script has to create a tmp copy of the ledger which is ugly, will not work for big ledgers, and has some problems for NFS mounted systems).   # RocksDB has snapshots support, which can help us in more efficient ledger catch-up.   # RocksDB works well on Windows    What needs to be done:   * Implement RocksDB implementation of key-value storage   * Integrate RocksDB into CI and CD   * Create migration script from leveldb to rocksdb   * Adapt `read_ledger` script to work with RocksDB and avoid creation of the ledger's copy"
Answer: 565221.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: "We need to make sure that txns timestamps is a monotonically increasing sequence, so that each new transaction (3PC batch) has a timestamp greater than the previous one.    It can be done as part of dynamic validation of a timestamp proposed by the Primary."
Answer: 569112.0

User story: "It's quite hard to read the log files now.    We need a tool to track each request: what stages it passed, what was the status, etc."
Answer: 576407.0

User story: "As of now we have just 1 big log file for base Node messages, plus all replicas.    It's better to split the log into the following files:    1) The main Node log for information related to all replicas    2) Each replica individual log files."
Answer: 576566.0

User story: "Once INDY-1176 is done, we should be able to get Node Log files without communication with Stewards.    Let's design and implement how we can do it easily without sophisticated Sovrin Dashboard and UI."
Answer: 587983.0

User story: "Node logs need to be shared and public.    So, we need to make sure that they don't have any sensitive information (private keys, seeds, etc.)"
Answer: 587990.0

User story: "A Trustee needs to be able to send a Request (not transaction) to restart the whole pool at the given time."
Answer: 587996.0

User story: "We need to have more intensive testing of the current view change protocol:   * that view is changed on performance degradation;   * that view is changed on disconnections of primary;   * that view change works properly with random delays;   * that view change works properly when some nodes in the pool are down;   * that view change happens when primary behaves maliciously (sends incorrect data for example);   * we need to test it also in a quite large and distributed pool    We need to design more scenarios and test them."
Answer: 628201.0

User story: "We should have an assumption to be able to have just one CLAIM_DEF (that is a key) for an ISSUER_DID.  If one needs to rotate a key, a new DID must be used. It means that ISSUER_DID is rather a CLAIM_DEF's DID (or key's DID).  So, we must check if there is already a CLAIM_DEF for a Schema-DID pair, and not allow to override it on ledger. We now do the same for Schema (that is we can not override Schema with the existent name-version-origin triple).    Tasks:  1) do not allow to override CLAIM_DEF on ledger for already existent schem-did pair;  2) update docs and diagrams so that it's clear it's not possible to create multiple CLAIM_DEFS for the same schema-did pair.  "
Answer: 638505.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 we have BLS signature over Domain State (domain ledger transactions) only, that is over NYM, CLAIM_DEF, SCHEMA, etc.  We need to have BLS muli-signature support over Pool State (pool ledger transactions such as NODE) as well to be able to perform catch-up more efficiently. With BLS multi-signature for Pool state, we could catch-up from on node and make sure that this is a valid state.  Find more details in [Observer Architecture|https://docs.google.com/document/d/1HcVp0V1RvgHanW_et84ttiga-eWkOaNyzhBzFwsWBIg/edit#]."
Answer: 772983.0

User story: "We need to support fully qualified DIDs in the form `did:sov:<value>`, not just `<value>`.  * If we see just <value>, we can assume the prefix is “did:sov:”   * If we see a prefix that isn’t “did:sov:“, we can potentially raise an error about an unsupported DID type.    Note that some DID formats may make different assumptions than Sovrin does about the length of a DID, whether it is case-sensitive, etc. We need to get in the habit of thinking of DIDs as being fully qualified. Our sample files should show this. Our wallet APIs should handle it. Etc. This is the foundation for us being able to have a single wallet/agent/agency that supports DIDs from the production Sovrin ledger as well as a test network--and it is the foundation for eventual interop with other ledgers like Bitcoin and Ethereum."
Answer: 1097635.0

User story: "- We need to have a documentation describing Indy project from the Product point of view  - It should point to the main goals of Indy, use cases and requirements.   - It should mention what differs Indy from other Blockchains  - We need to have this doc public on GitHub  (in plenum and node repos)."
Answer: 686074.0

User story: "- We need to have enough technical documentation available in our Github repos   - We need to describe how Plenum works, what are key concepts and features, why it was created that way, what are the differences from other blockchains  - We need to have at least one Markdown document in plenum/node repos (doc folder) describing all this  - We need to have a link to this doc from README."
Answer: 686079.0

User story: "Testing Node Performance and understanding the overall throughput and performance of the Validator Pool. This is 1 of 3 tickets regarding transactions per second (ticket 1 is for a 25-node validator pool, ticket 2 is for a 35-node validator pool).     Spec sent last week to replicate test scripts and setup with libindy   # Set up local environment (until Kelly hands over his - possibly next 2 sprints)   # Run a pool with 50 Validator nodes   # Document results, report to Engineering/Product    Success criteria: report detailing transaction per second at 50 validator nodes"
Answer: 973169.0