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: "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 3 is for a 50-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 35 Validator nodes   # Document results, report to Engineering/Product    Success criteria: report detailing transaction per second at 35 validator nodes"
Answer: 973169.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 2 is for a 35-node validator pool, ticket 3 is for a 50-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 25 Validator nodes   # Document results, report to Engineering/Product    Success criteria: report detailing transaction per second at 25 validator nodes     "
Answer: 691567.0

User story: The validator-info diagnostic script is an excellent addition to the Indy suite.  Here are a few additional features that will enhance its usefulness:   # In the verbose human-readable output, indicate the time (which must include the timezone) in ISO 8601 format.  For example: "Current time:    2017-12-15T15:53:00+05:00"  # In addition to the DID and verkey, report the BLS public key   # Indicate the nodes that are the current primaries.  In the verbose human-readable output, this can be indicated by the primary number in parenthesis after the name of the nodes that are primaries, in this fashion:       {code:java}  Reachable Hosts: 10/10  RFCU  australia   (1)  brazil      (0)  canada  england     (2)  korea       (3)  mapleleaf  ricFlair  singapore  virginia  {code}  For the json output, this could be done using a hash instead of a list for the nodes as shown, or by another means:  {code:java}  {  "RFCU": null,  "australia": 1,  "brazil": 0,  "canada": null,  "england": 2,  "korea": 3,  "mapleleaf": null,  "ricFlair": null,  "singapore": null,  "virginia": null  }  {code}
Answer: 701218.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: *Version Information*  indy-node 1.2.49  indy-anoncreds 1.0.11  indy-plenum 1.2.29  sovrin 1.1.7    *Major Fixes*  INDY-759 - validator maintains pace with network, exactly 12 transactions behind  INDY-895 - Wrote a migration that eliminates the rudimentary difference between ledgers  INDY-231 - Fixed a bug with a wrong upgrade time  INDY-157 - Fixed a bug with failed node restart after canceled pool upgrade  INDY-801 - Sovrin logs are insufficient for failed upgrade  INDY-917 - Node gets wrong upgrade_log entries after restart and runs the wrong upgrade  INDY-231 - Upgrade scheduled to future date happened in current date on part of nodes   INDY-701 - More earlier pool_upgrade was not happened when there were scheduled upgrade to future date.  INDY-932 - Validator runs instance change continually (issue found on live pool)  INDY-909 - New nodes added to existing pool are unable to participate in consensus after the upgrade  INDY-541 - Node logs repeat message "NodeRequestSuspiciousSpike suspicious spike has been noticed"  INDY-941 - Unable to catch up agent if a validator is down  INDY-907 - Enhance catch up mechanism to let it work with large ledgers  INDY-849 - Pool can't be restored after losing consensus if at least one view change was happened  INDY-941 - Unable to catch up agent if a validator is down  INDY-958 - Pool is unable to write NYMs after BLS keys enabling  INDY-953 - The last pool node is failed to upgrade during pool upgrade  INDY-954 - State Proof creating is fixed  INDY-949 - State Proof verifying is fixed    *Changes and Additions*  INDY-670 - Signed State implementation  INDY-790 - State Proofs implementation  INDY-829 - Remove all non-Indy branding from indy-plenum repo  INDY-855 - Remove all non-Indy branding from indy-anoncreds repo  INDY-830 - Remove all non-Indy branding from indy-node repo  INDY-877 - Backward compatibility of nodes with state proofs support with old clients  INDY-880 - Supported rebranding in sovrin package  INDY-891 - Supported rebranding in Docker and Vagrant environments of sovrin-environments  INDY-831 - Support of multiple pool networks by Indy Node  INDY-832 - Support of multiple pool networks by Indy Client (CLI)  INDY-833 - Proper file folder paths for system service  INDY-927 - Client needs to be able to send read requests to one Node only  INDY-928 - Client needs to be able to make sure that we have the latest State Proof     *Known Issues*  INDY-960 - Node is broken after load_test.py run    *Additional Info*  Mapping of all file/folder changes is here: https://docs.google.com/spreadsheets/d/1A84H8knCtn8rrTirzxta8XC1jpHBjvQiqrxquTv6bpc/edit#gid=0
Answer: 706230.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 adding of a txn to the ledger consists of two steps:  - add txn to transaction log  - add txn to the tree (hash store).    It's possible (see, for example, INDY-893), that Node may stop/crash in between. So, we may have a bit inconsistent data.     We will be able to recover the ledger (merkle tree) from txn log in any case, so this is not so critical from recover point of view.  It may be more critical if something wrong happens in between without crashing, so that will continue working with inconsistency between txn log and the tree."
Answer: 1019394.0

User story: "If client sends a batch of Requests, it would be nice to receive a a batch of Replies for it."
Answer: 716116.0

User story: "As of now, we return State Proof for read requests only.  We need to extend it to present state proof for write requests as well, so that a client would be able to connect to one node only for both write and read requests."
Answer: 727498.0

User story: "- Need to analyse recent stories and add required guidelines   - Make the guidelines public to share with the Community    Examples of guidelines:  - file folder guideline;  - keys guideline"
Answer: 1009040.0

User story: "It's perfectly possible that we may need to change Node-to-Node communication (add new messages, change protocol, ass/remove fields from messages, edit messages, etc.).    Option1:  Always require UPDATE on the same time, so we can assume that our pool is always at the same version.  - It may mean that our pool is unavailable for a couple of minutes, but probably it's fine for now, since we don't have big load, and we can always announce a maintenance time    Option2:  Define a 'pool protocol version' as a minimal version of nodes in the pool. We can get this version from config ledger (NODE_UPGRADE txn).  Have protocol-version-dependent code, so that we don't send new messages until all Nodes in the pool understand the new type of messages.  - it may slow down providing hotfixes, so probably should be combined with Option1.    Option3:  Each Node-to-Node message has a version, and we should send all versions of a message, so that both old and new Nodes can understand it.  - it doesn't help when we change the whole protocol, so we need Option2 there."
Answer: 742046.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, multi-sigs are created on every Request. But if there are no Requests in a pool, then the state and multi-signatures may become outdated.    So, a Primary needs to initiate re-signing of the same state periodically to have up-to-date state (for the latest pool ledger).   It will help to solve two problems:   - Have up-to-date multi-signature (with the latest timestamp)   - Have multi-signature for the latest pool ledger (the client can use the latest pool ledger in most of the cases)    All states (for all ledgers) need to be re-signed periodically.         *Acceptance criteria*   * Implement periodic BLS re-signing of all states (for all ledgers). It can be done via existing PrePrepare msg, or via a new message (decide when creating a PoA).   * Re-sign period needs to be configurable (config file for now). Default is 1 min.   * It should be possible to disable/enable the feature in config.  * An INFO level log message is issued which states "Freshness was updated through consensus."
Answer: 746286.0

User story: "As of now, Results with state proofs contain the time when transaction was written to the Ledger.  It may be enough for some of the cases, but in general we also need to make sure that a Node returned a State Proof for the latest state. It's especially critical if we get reply from one node only, and this node can be malicious.    *Example:*  - There is a NYM with seqNo 10 and time X. Then the key was rotated in a NYM with seqNo 20 and time Y.  - We send GET_NYM to a node willing to get the latest key.   - But the Node is malicious, and returns result as it was at the time X and seqNo 10. A client doesn't know if this is the latest state or not.    *Possible solution:*  - we need to sign not only domain and pool state roots as of now, but also the timestamp of this state (and possibly seqNo as well).  - so, we create multi-signature over `state_root_hash+txn_root_hash+pool_state_root_hash+state_ts+ledger_id`  - include domain_state_ts and domain_state_last_seqNo into State Proof with each Reply  - With this approach, once client receives a Reply, he validates the multi-signature (against returned  `state_root_hash+txn_root_hash+pool_state_root_hash+state_ts+ledger_id`). So, a client can be sure that the result is not older than specified timestamp.  The client can later decide if the transaction is fresh enough for him. If not, he can ask another Node (another Observer for example), or fall back to f+1 replies.    The proposed solution can not guarantee that the result is really the latest one (but actually we can not guarantee it in general in BFT system, especially once we introduce Observer Nodes). But the provided information should be enough for the client to decide of the returned result is fresh enough for him.  "
Answer: 746461.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: "With State proofs implemented, we can reduce load on live pool dramatically, since we can send read request to one Node only.  We need to make it possible for existing client/CLI.    Think about how to do it best. Possible options: send reqs to Nodes in round robin or randomly (if there is state proof returned)."
Answer: 748075.0

User story: "blocks https://evernym.atlassian.net/browse/CO-675"
Answer: 750559.0

User story: "Blocks [https://evernym.atlassian.net/browse/CO-355]    and [https://evernym.atlassian.net/browse/CO-675]     "
Answer: 750560.0

User story: "The changes made in scope of the platform rebranding from Sovrin to Indy must be supported in the environments being deployed from {{sovrin-environments}}."
Answer: 780704.0

User story: "* We need a way to record on the ledger-like log without consensus  * Significant events should be logged there.  * Define if it is public.  * Think about security vulnerability. "
Answer: 1062342.0

User story: "We need a signal or alarm (external measure) when a pool stops functioning. If the pool is no longer accepting new transactions or unable to perform a read action.    *Basic Requirements *  Pick a timeframe, 60/90 mins, then an alarm goes off.   Introduce a simulation for this.   Keep rotating a key on a test account.   When a transaction cannot be written, have an email sent. Need to define who should be in the email list and how it is controlled.  Need a system that shows the exact way it works externally.    "
Answer: 1059876.0

User story: "We need to support evolving of transaction in the Ledger (adding new fields, changing data types, etc.)  https://docs.google.com/document/d/1Y2e_J2sWii2f6V6aS4g8Z6bq0g9Tqr-VMKbJWx86mRI/edit#  We can do this by having a VERSION field in each of the transactions"
Answer: 781213.0

User story: "Non-Indy branding and names was removed from documentation in {{indy-plenum}}, {{indy-anoncreds}} and {{indy-node}} repositories in scope of INDY-829, INDY-855 and INDY-830. However there are other resources with Indy documentation (e.g. Google Drive). In scope of this ticket remove non-Indy branding and names from documentation in such repositories.    For the purposes of this ticket, the scope is all Google Doc references that are made in {{hyperledger/indy*}} repositories. It also includes links found in the Indy wiki. Any additional documents that need changes should be submitted as separate tickets."
Answer: 782509.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: "There is file folder paths re-factoring in the scope of INDY-833. It makes valid folder layout for output deb packages and provides required migration.   But it doesn't assume any deep re-factoring of the code base.    We need to perform the following re-factoring on the code level:  1) Separate a number of paths in the config responsible for outputs  2) These paths must be absolute  3) These paths must be configurable for different installations (default, CLI, tests, deb, rpm, Windows, etc.)  4) We need to re-factor the code to not use paths from config only during initialization  5) We need to re-factor the code to use proper paths  6) We need to get rid of BASEDIR (there is no BASEDIR anymore, all paths are absolute).  7) We need to make tests use special config and be consistent.  8) DEB packages should use proper system-dependent configs  9) Required migration must be provided    "
Answer: 788288.0

User story: "This ticket can go two ways:   * an explicit explanation on how to upgrade a node control tool first and do an upgrade which requires the new tool can be created (an approach with intermittent releases)    * a specific mechanism can be developed and injected in the tool's code which allows code refresh before running the migrations"
Answer: 1084038.0

User story: "As of now, we use and support only the multi-sig for the latest state.   We need to support multi-sig for historical states to be able to query historical data.    The multi-sig storage (key-value db) uses state root as a key, so it's pretty trivial to store sigs for all required old states.   We need to support some sort of catch-up for multi-sig storage.  We need to send multi-sigs  for previous batches on timeout if we didn't send new batches."
Answer: 802629.0

User story: "Current CD pipeline is complex and contains closed parts:  - SovrinHelpers library that is setup as jar on Jenkins  - Secrets: Keys and accounts    Community suggests the following:  - Split CD pipeline to CI and CD parts  - CI part must be as simple as possible. Ideally, doesn't require specific Jenkins setup to be executed  - CD part can keep all current CD logic and secrets."
Answer: 806858.0

User story: "We need to remove all non-Indy branding and names from indy-anoncreds repo:  * Package names  * Code primitive names  * Paths  * Documentation    Ideally, if full-text search for Sovrin and Evernym will return nothing."
Answer: 806870.0

User story: "From conversation with [~<USER>:  {quote}  I am in a meeting talking about plugging in a sovrin piece on top of indy to deal with tokens. In order to do something like this we would need to be upgrading using the sovrin package not the indy package. I don't have details yet it is still being designed.  {quote}"
Answer: 806950.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: *Version Information*   indy-node 1.1.37   indy-anoncreds 1.0.10   indy-plenum 1.1.27   sovrin 1.1.6    *Major Fixes*   INDY-786 - fixed problem when the pool was writing transactions when more than F nodes were stopped   INDY-808 - Manual upgrade fixed   INDY-760 - fixed problem when the pool was broken after processing lots of transactions at once   INDY-804 - fixed problem when the pool doesn't come back to consensus (case when less than n-f nodes are alive)   INDY-761 - partially fixed problem when the pool responded with outdated data    *Changes and Additions*   INDY-716 - "debug" mode for tests was moved to parameter   INDY-800 - Log levels were changed on some debug level message to an info level    *Known Issues*   INDY-849 - If the pool loses enough nodes and cannot reach consensus when enough nodes become available the pool still will not reach consensus.    Workaround for INDY-849 - If you restart all nodes in the pool it will start reaching consensus again.
Answer: 807928.0

User story: "It must be possible to easy setup and use Indy Node, Indy CLI and Indy SDK on one PC."
Answer: 811102.0

User story: "CI parts of all pipelines must be moved to Hyperledger infrastructure."
Answer: 811109.0

User story: "Current CD pipeline is complex and contains closed parts:  - SovrinHelpers library that is setup as jar on Jenkins  - Secrets: Keys and accounts    Community suggests the following:  - Split CD pipeline to CI and CD parts  - CI part must be as simple as possible. Ideally, doesn't require specific Jenkins setup to be executed  - CD part can keep all current CD logic and secrets."
Answer: 811113.0

User story: "Current CD pipeline is complex and contains closed parts:  - SovrinHelpers library that is setup as jar on Jenkins  - Secrets: Keys and accounts    Community suggests the following:  - Split CD pipeline to CI and CD parts  - CI part must be as simple as possible. Ideally, doesn't require specific Jenkins setup to be executed  - CD part can keep all current CD logic and secrets."
Answer: 811114.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 use proper file folder paths for system service: usr, var, etc, user-configuration vs system configuration, folders for network configuration so multiple networks can co-exist    The most urgent task here is likely the file and folder location refactor, we will want to reorganize how things are laid out as soon as we can, before we pick up more production use cases and grow the network.  I walked through this with Dan and Devin and have attached an outline of what we discussed (see attached image).  Notice the paths under /var, /etc and $HOME/.indy.  The variables at the top of the board could be used as potential substitutes.  We also talked about having some sort of environment variable(s) so that system users can overwrite the home folder location to something more suitable.  Notice that this was from a brainstorming session, there is nothing set in stone.  Please add your thoughts and suggestions.  Obviously some plan as to how we can migrate files from existing locations in the current network will be important.   I look forward to hearing what tickets you think will be needed."
Answer: 811119.0

User story: "It should be possible to choose which network to use from the same install of Indy CLI.    This is important for test networks, private network shards for regulatory reasons, development could use this, and it helps prove Indy can be used independently of Sovrin -- reduces open source fork risk.    It is related to path refactoring in INDY-833"
Answer: 811135.0

User story: "It should be possible to choose which network to use from the same install of Indy Node.    This is important for test networks, private network shards for regulatory reasons, development could use this, and it helps prove Indy can be used independently of Sovrin -- reduces open source fork risk.    It is related to path refactoring in INDY-833"
Answer: 811136.0

User story: "We need to remove all non-Indy branding and names from indy-node repo:  * Package names  * Code primitive names  * Paths  * Documentation    Ideally, if full-text search for Sovrin and Evernym will return nothing."
Answer: 811158.0

User story: "We need to remove all non-Indy branding and names from indy-plenum repo:  * Package names  * Code primitive names  * Paths  * Documentation    Ideally, if full-text search for Sovrin and Evernym will return nothing."
Answer: 811191.0

User story: "Currently in sovrin there are automated tests of unit and integration levels only. In scope of this story automated tests of system level must be introduced into sovrin."
Answer: 1098316.0

User story: "*Version Information*   indy-plenum= 1.1.25   indy-anoncreds= 1.0.10   indy-node= 1.1.35   sovrin= 1.1.6    *Major Fixes*   INDY-808 - Fixed problem with migration during manual upgrade   INDY-765 - Fixed problem with message length limitation (permanent solution of INDY-25)    *Changes and Additions*   Implemented command line tool to provide validator status (INDY-715)"
Answer: 817017.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:   *Version Information*  indy-plenum= 1.1.24  indy-anoncreds= 1.0.9  indy-node= 1.1.31  sovrin= 1.0.4    *Major Fixes  *    INDY-410 - Stewards can now demote and promote their own nodes  INDY-466 - Fixed problem with timezones for timestamp in transaction  INDY-25 - Limited incoming message size from 128k to 128MB (Temporary solution)  INDY-378 - fixed `send CLAIM_DEF` command  INDY-725 - mask private info in CLI logs/output  INDY-8 - fixes crashes on ubuntu 17.04  INDY-211 - python interpreter is executed in optimized mode  INDY-223 - memory leak fixes  Some minor stability fixes        Changes and Additions       * New ledger serialization is supported and Leveldb is used as as a storage for all ledgers : msgpack is used for the ledger serialization (both transaction log and merkle tree)   *     *      The new serialization change created changes to the directory structure for the nodes. The directory name changes are located on a node under .sovrin/data/nodes/<node name>/<directories>. The change removes the ledger files as plain text files and creates them as binary files. A new tool was created to view the ledger entries called read_ledger and is described below.     * Genesis transaction files are renamed adding a _genesis to the end of each file name.   *      * Added the commands to the POOL_UPGRADE to support downgrade and re-installation. However both have issues and should not be used at this time (INDY-735 and INDY-755).   * The tool read_ledger.py was created to allow access to reading the ledger or getting a count of the transactions. You can run read_ledger as the sovrin user with --h to get a list of commands.   * Fixes to upgrade procedure (in particular and issue which caused an infinite loop INDY-316)   * CLI Changes   *     * New CLI command was added to ease the process of rotating a verification key (verkey). The command is `change current key` or 'change current key with seed xxxxx'.     * Modified terminology in code, CLI and documentation    *      * Changed 'keyring' to 'wallet'     * Changed 'link' to 'connection'     * Changed 'invitation' to 'request'     * Changed 'identifier' to 'DID'       * Improvements to log messages   * Publishing only to repo.sovrin.org   *     * In your sources.list you only need the entry "deb https://repo.evernym.com/deb xenial stable".    
Answer: 829600.0

User story: "- Support generation of State Proofs creation for client requests  - https://github.com/hyperledger/indy-plenum/pull/364  - https://docs.google.com/document/d/1x94NtronycZUppYnO_847yJ06f33QT-L90xdL1ZbTiE/edit?ts=59a687f1#"
Answer: 831634.0

User story: "When ticket INDY-709 is Live, install instructions should no longer require anyone to add repo.evernym.com to /etc/apt/sources.list, or to add evernym's PGP key to its signers. Update all necessary instructions. "
Answer: 839392.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: "INDY-25 was meant to limit transaction size. The implementation limits the message size and not the individual transaction size to 128k.    *Problem*  We need to be able to limit the transaction size by type of transaction and not by the size of the message. One large message could contain several hundred transactions. In the case of the load_test.py script when sending 400 transactions at once a single message is sent and then rejected due to message size.     *Use Case*  The best way for users to add large amounts of NYMs to the ledger will be in sending large batches of transactions within a single message. We should be able to break out the message and deal with each transaction individually.    Limiting the size by transaction type will keep transactions within a reasonable range without giving a blanket size to all transaction types. Adding a NYM transaction does not need to be large while adding a schema or CLAIM_DEF will require a large limit.    *Requirement*  Limit size of transactions by transaction type and not by message size.      "
Answer: 839795.0

User story: "* Add scenario for upgrade to acceptance tests:   ** usual upgrade;   ** force upgrade;   ** data for testing of migration;   ** cancellation of upgrade;   * Add according row to Test Matrix - RC - Sovrin - INDY spreadsheet."
Answer: 841391.0

User story: "* Add scenario for view change to acceptance tests:   ** caused by stopping services on primary;   ** caused by demotion of primary;   ** caused by decreasing of primary node performance.   * Add according row to Test Matrix - RC - Sovrin - INDY spreadsheet."
Answer: 841393.0

User story: "* We support migration scripts during update   * We support downgrade on apt level (it's possible to install a lower version)  * However, migration scripts are always called AFTER code upgrade/downgrade. This is fine for upgrades, but doesn't work for downgrades, since we need to have the current code to call the downgrade migration script.  * So, for downgrade cases migration scrip must be called BEFORE code downgrade."
Answer: 1130512.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: "Please add the requested information to the Release Notes, which includes some important information. "
Answer: 869870.0

User story: "Support all transaction types related to revocation - [Anoncreds Design|https://docs.google.com/document/d/1pqyvXCcGAWFm0mHWIh9PsJp0lIdIraUsntf_3HcD294/edit]  "
Answer: 870426.0

User story: "Design a way to store and get tails for anoncreds revocation in SovrinSee anoncreds design for details: [Anoncreds design|https://docs.google.com/document/d/1pqyvXCcGAWFm0mHWIh9PsJp0lIdIraUsntf_3HcD294/edit#]- We have an entity we call 'tails'. It's an ordered sequence of elements used for non-revocation proof.- The tails may require quite huge amount of data (~200MB).- The tails are created and uploaded by Issuers.- The tails are required (so must be available for download) for both Provers and Verifiers.- We can cache tails, so we can download them only once.- We need to find a way how to store and transfer tails (one of the options is bit-torrent style).- We probably can not just store tails on Issuer side, as Issuer may be offline.- We had a research on Torrents (https://docs.google.com/document/d/10QUo4xRFaEM9nYCcmpZrOfmWbe44L8zELvOYERS2Eh0/edit)PoA: [link|https://docs.google.com/document/d/15DD6HTZu8ZCyyaBu1jfGyvqEPHDSVHX2ft7Q9AjaQlc/edit]"
Answer: 870428.0

User story: "In SPLAT-11 we created a procedure of building deb packages. Now we need a way to publish these packages.Ubuntu's master repo looks a good alternative (ppa, or custom repo, or FTP are other alternatives): http://askubuntu.com/questions/16446/how-to-get-my-software-into-ubuntu* Think whether we should publish only release packages to the Ubuntu's master repo, or all packages including dev packages (created by CI on a daily-base).* Define the process of publishing to the master repo, what pre-requisites do we need.* Extend CI pipelines to include publishing step.See Pipelines Design for details: [Sovrin Pipelines Design|https://docs.google.com/document/d/1hKwXzX3vsKN97R9F3XVzpCZ7WBOYkyCLuOyrvhCH048/edit#]"
Answer: 870425.0

User story: "We need to run sovrin-client tests in GoCD for Windows 10* Prepare a VM for Windows 10* Install GoCD agent to the Windows machines* Connect Windows GoCD agents to the GoCD server* Enhance test pipelines for ledger(-dev), anoncreds(-dev), plenum(-dev), sovrin-client(-dev), sovrin-common(-dev) to run tests on Windows 10 (in parallel with ubuntu)* Check that it starts all integration tests and reports results.Please refer to the following design doc: [Sovrin Pipeline Design|https://docs.google.com/document/d/1hKwXzX3vsKN97R9F3XVzpCZ7WBOYkyCLuOyrvhCH048/edit#]"
Answer: 870426.0

User story: "CI build pipelines should be able to create Docker images (for both master and stable branches)PoA:# add task of building docker images for the sovrin-client into deploy pipelines# test"
Answer: 870425.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: "* Run a simple test to check that docker image can be launched and CLI can be started (for sovrin-client-dev-deploy and sovrin-client-master-deploy)Please refer to the following design doc: [Sovrin Pipeline Design|https://docs.google.com/document/d/1hKwXzX3vsKN97R9F3XVzpCZ7WBOYkyCLuOyrvhCH048/edit#]"
Answer: 870425.0

User story: "* Create Evernym user on dockerhub* Create a script that uploads image to dockerhub using just created Evernym account* Integrate the script into the pipelines (sovrin-client-dev-deploy and sovrin-client-master-deploy)* Note that we deploy dev and releases separately (releases are deployed only after manual approval from QA)Please refer to the following design doc: [Sovrin Pipeline Design|https://docs.google.com/document/d/1hKwXzX3vsKN97R9F3XVzpCZ7WBOYkyCLuOyrvhCH048/edit#]"
Answer: 870425.0

User story: "I should be able to: # Create, name and save a JSON proof definition so I (as a Prover and Owner) can request and offer proofs from the CLI.# The definition can be stored locally (no need to write it to the ledger)h2. [PoA|https://docs.google.com/document/d/10Td0kMl6wOv53OcqcLqhaK_sp_q7k21lJVex7T1l8NQ/edit]"
Answer: 870426.0

User story: "1. Implement and publish a way for claims and proofs to be shared. 1.1 The CLI should use a well defined schema for claims and proofs.2. Publishing the selected way3. Nathan must pass off on this POA4. Should have a serialization example for: claim offerclaim requestproof offerproof requesth2. [Plan of Attack|https://docs.google.com/document/d/1Mer6szvBotAw-u_bC_fcQmXgmoperTl2xqQ2rnJEElQ/edit#]"
Answer: 870428.0

User story: "h2. [Plan of Attack|https://docs.google.com/document/d/1yhPDi9viKErEsvP4kBznJZlZm3dPJid4pOBIkkvGimw/edit]"
Answer: 870426.0

User story: "Multisig mechanism in consensus protocol.   This is on hold as we might do a different signature scheme called BLS as shown here [https://github.com/evernym/anoncreds-priv/blob/bls-sig/anoncreds/bls_experiment.py]. Please find the paper attached. [^BLS-BFT.pdf]. Here is a supporting doc [https://docs.google.com/document/d/1WRkqNqXXi1LoVxZu0C353uR0KRatoQuvrV_UZNDuNcc/edi|https://docs.google.com/document/d/1WRkqNqXXi1LoVxZu0C353uR0KRatoQuvrV_UZNDuNcc/edit]  h3.  "
Answer: 870424.0

User story: "POA:The multisig contains the signed root hash of the state trie, transaction tree and sequence number of the transactions. Multisigs for different ledgers go into their respective ledgers, so a multisig over pool ledger goes into the pool ledger, multisig over identity ledger goes into the identity ledger and so on."
Answer: 870425.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: "POA:We need to distinguish between requests during 3 phase process that go in different ledgers. So there would be different multisigs for each ledger. Only the pool ledger needs to be anchored to the different ledgers, so the identity ledger and config ledger would have periodic entries specifying the sequence number from the pool ledger . Each ledger has a unique id. Pool ledger has id 0, identity ledger has id 1, config ledger has id 1. Identity ledger and config ledger will have entries like this: {type: “anchor”, ledger_id: 0, root_hash: af190be3341ac, seq_no: 32}"
Answer: 870426.0

User story: "POA:Sovrin client fetches the last anchored record of the pool ledger before the state proof. It takes the anchor record, and then gets (each client has the same pool ledger as nodes) the node verification keys corresponding to the root hash in the anchored record. Once it has the correct verification keys, it verifies the state proof"
Answer: 870426.0

User story: "eg, check if verkey is correct given last state proof"
Answer: 870425.0

User story: "We need to show build status of all projects related to sovrin on public repositories.Refer this screenshot  !Badge-github.png|thumbnail! Refer below link for documentation on how to do it.https://github.com/dwyl/repo-badges"
Answer: 870426.0

User story: "Given I am an Organizational Guardian over some Dependents (defined in the [Sovrin Trust Framework|https://docs.google.com/document/d/1n6if3-JZw8BaRmxm3B9X5mKj_IZPHLqi_khHFOrY-XA/edit#]), and I already have access to the Dependent's Agents through a Partner Agency, I should be able to: 1. Give permission for those Dependent's Agents to allow their Organizational Guardian's Agent (me) to read/write data to their vaults2. Give permission for those Dependent's Agents to communicate with their Guardian Agent (me)"
Answer: 1149118.0

User story: "Given I am a CLI user and I can create and name JSON proof and claim definitions I should be able to: 1. I should be able to type some command in the CLI to see a list of all my claim and proof defs I've created and named. 3. I should be able to delete a claim definition in the CLI"
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 a CLI user and I have at least one connection, I should be able to: 1. Offer a claim to one of my connections. (This is the equivalent of sending an invitation to send me a claim request)Examples:-A business invites Alice to request a claim containing its valid business license-Joe offers a claim to Alice saying she has blonde hair.-Alice's doctor offers her a claim saying she is in good health.-Alice's insurance company offers her a claim saying Alice is defensive driver.-Ebay issues Alice a claim saying she has 99.98% positive seller feedback.-Patrons offer claims to a restaurant saying it has great service.-Movie critics offer claims to their connections saying a certain movie was worth watching.*POA*_Assumptions_* sender knows endpoint and verkey of receiver* standard claim definitions are already established and mutually agreed upon by all parties involved_POA steps_* Create a CLI command `offer claim <claim-name-version>`. Add a command in sovrin cli. In file sovrin/cli/cli.py, add regex to interpret cli command, add it to lexers and completers. Add command action handler.* offer command handler will get the claim from available claims and will send to receiver* On receiver agent create a handler that accepts incoming claims, cli will need to register to this event, and call already created method which receives claim after `accept invitation`. Once we have available claims added via same method call after `accept invitation`, it will be printed on cli and user can request claim, if he wants."
Answer: 870426.0

User story: "Using claims in my vault, I should be able to:1. Offer a proof to one of my connections. 2. The proof I offer does not contain the proof, it is simply an invitation for a relying party to send a proof request. This story does not cover actually sending any proofs, only offering to send them. Examples: - A restaurant offers proof to Alice of having 25 convenient locations in Utah.- Alice offers proof of her school teaching license to perspective employers and schools.- A business offers proof of its patents to investors.- Alice moves home and offers a proof of her new address to her bank and cellphone provider.PoA- After successful connection a Prover will offer available proofs to end-user(Alice)- Create a CLI command which will send message to Alice about proof details- Command can be something like - -- {{offer proofs <proof_name>}} - Create message having proof details - then send message to Alice’s endpoint using command -- {{offer proofs <proof_name>}} command- Above command will execute {{sendMessage(msg, endpoint_for_alice}} of CLI- {{sendMessage(msg, endpoint_for_alice}} method with will send a message to Alice with all details (proof details and how to get them)- At Alice’s CLI there will be a handler to print incoming message on Alice’s CLI."
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: "Given: # I am a CLI user (Issuer)# I have at least one connection that has sent me a claim request:I should be able to:# Issue a claim to the requester of the claimSo that I can: [Plan of Attack|https://docs.google.com/document/d/1S4ZPZcO2cMj7-FQKC2b3ZKZSf4wJACJ2m5f8-1gXr9g/edit]"
Answer: 870426.0

User story: "Given I am an Organizational Guardian (defined in the [Sovrin Trust Framework|https://docs.google.com/document/d/1n6if3-JZw8BaRmxm3B9X5mKj_IZPHLqi_khHFOrY-XA/edit#]) and I've created at least one Dependent, I should be able to: # Request a Partner Agency to create an Agent for each Dependent Sovrin Identity I create. # Give me an endpoint for each Dependent's Agent which the Partner Agency creates for me.*[Plan of Attack|https://docs.google.com/document/d/1wOpwDQXOH5F1GPCfhDpvR_I3G-Zu2DkOJDbZd49VMOg/edit]*"
Answer: 1149118.0

User story: "Given I am a Guardian, I should: 1. Be the only Identity which can write to the Agents of the Sovrin Identities which I've created and am Guardian over. Note: When I am no longer Guardian, and some people assert control over (take control of their private keys) their Sovrin Identity, they will be able to decide who can write to their agent."
Answer: 1149118.0

User story: "There is uncertainty as to whether the nonce generation and verification as represented in the Getting Started guide (and the Bulldog demo) is fully implemented and tested. This is going to be very important when Unicorn begin their testing.1. The nonces should be used and visible where claims and proofs are shown here: https://github.com/evernym/unicorn/blob/master/unicorn/demo/unicorn_phase_0_test.scripth2. [Plan of Attack|https://docs.google.com/document/d/165r9nLCTfzMMRnbdeK0xuiN0KoNjPrZqhICAcdnqt1c/edit]"
Answer: 870426.0

User story: "To support CLI to CLI communication, the embedded CLI Agent endpoint should be made accessible to those who know the Owner's chosen identifier.We will need to consider the security implications of this, and how we might traverse NAT and firewalls without requiring Evernym to operate a cloud-based port forwarding service...[POA|https://docs.google.com/document/d/1cWB6izREVuNG0Cv3wwcaDejqeiUEyrdGAcTWZQugIkY/edit#]"
Answer: 870428.0

User story: "From James: Downloading .sovrin files before they can be opened by the CLI is awkward -- we should support loading files from a URL directly in the CLI."
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: "As a Guardian, I should be able to: 1. Create new Dependent Sovrin Identities2. Specify the Agent endpoint for the identities I createExample: -Refugee camp creates Sovrin Identities for each refugee, and becomes the Guardian for them, managing the identifiers until the refugees can assert control over their identities. An Organizational Guardian is a type of Trust Anchor which can create a new Dependents. A Dependent is an Individual who must depend on a Guardian to administer the Individual’s identities. Under the [Sovrin Trust Framework|https://docs.google.com/document/d/1n6if3-JZw8BaRmxm3B9X5mKj_IZPHLqi_khHFOrY-XA/edit#], all Dependents have the right to become Independents. Mutually exclusive with Independent.h2. [Plan of Attack|https://docs.google.com/document/d/1oRtl9_p9mkXJlvzL5mghMnvStj5pYNkzUPu2DXtdmYw/edit]"
Answer: 1149118.0

User story: "[PoA|https://drive.google.com/open?id=1EEnplkhhqbxfcmFdYADtJy1cjN4aRxAhxOeVQt2xlNM]"
Answer: 870426.0

User story: "[PoA|https://drive.google.com/open?id=1EEnplkhhqbxfcmFdYADtJy1cjN4aRxAhxOeVQt2xlNM]"
Answer: 870426.0

User story: "Stewards should not be allowed to have keys, only authorized identifiers. A Steward’s Authorized Rep should be able to do anything the Steward can do today.[PoA|https://drive.google.com/open?id=1EEnplkhhqbxfcmFdYADtJy1cjN4aRxAhxOeVQt2xlNM]"
Answer: 870426.0

User story: "See #3 of [Sovrin Platform Requirements MASTER|https://docs.google.com/document/d/1cglrYjY5UKWF7e5F1FhwOMoJLNGrShDHeoGw7PUama0/edit#] doc"
Answer: 870427.0

User story: "See #4 of [Sovrin Platform Requirements MASTER|https://docs.google.com/document/d/1cglrYjY5UKWF7e5F1FhwOMoJLNGrShDHeoGw7PUama0/edit#] docSupport owner/control sectionsNote to person writing PoA: include in the PoA which DDO sections you recommend to include, and which to omit, and give justification for your recommendation.Include mechanism for ultra-fast transaction signature verification. We need to make sure that we're not having to deserialize a json DDO structure and navigate it to find the key. That would be too slow. We may have to have a simple key-value store for verkeys. Or it could be some kind of LRU cache. Please recommend an approach and justify.This does depend on the Patricia-Merkle Trie. Here is the repository. https://github.com/evernym/stateOld DID/DDO Design document link: https://docs.google.com/document/d/1UGyoLlmv9OMBi-EStDrLFvY6URwlN4hSCfXghRbSgLo/edit#"
Answer: 870426.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."
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: "Includes rate numbers like avg. throughput, avg. latency., identifiers added over time, view changes over timeTotal numbers like total txns, view changes, network uptimeInclude graphsTo the Engineer who is doing the PoA: look at what's already been done by Khagesh and Andrey G. Recommend the metrics we should show. Also, suggest efficient vertical slices. This is not specified in great detail, because this first pass doesn't need to look amazing. Just get it functional. Use the PoA as an opportunity to specify the requirements you think we need, and we can review together.h4. [Plan of Attack|https://docs.google.com/document/d/1p0z0kMTXIiq9LKKjMAIEeef3sy87ShYfQHx7vMTgTnw/edit]"
Answer: 870426.0

User story: "See #5d of the [Sovrin Platform Requirements MASTER|https://docs.google.com/document/d/1cglrYjY5UKWF7e5F1FhwOMoJLNGrShDHeoGw7PUama0/edit#] doc    As the 'budget owner' who pays for the validator node to stay running, I need to see:    # How many transactions my node is participating in?  # The logs on my machine# My node is participating in consensus  # Ongoing thru-put of the Network  #  (optional) if my node is slower/faster than the average node on the network    * Can use or re-purpose the GUI that Andrey G built to help you complete this story    *From Jason:*  Add to dashboard metrics by Steward and Trust Anchor. (This creates visibility into behaviors on which, in the future, other Stewards and Trust Anchors can take action against offenders.)"
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.The following plan of attack assumes usage of ZeroMQ, another option can be RPCh4. [Plan of Attack|https://docs.google.com/document/d/1KSJUkRbmYdUB0bx5_BULF5T8oRqKkuCNRY679JL9g7E/edit]"
Answer: 1178205.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 (organization or individual) and not already a Trust Anchor, and I've received a Trust Anchor Invitation, I should be able to: # Create ONE Trust Anchor Identity# I should NEVER be able to create more than ONE Trust Anchor Identity# It is required that I agree to the Identity Owner Agreement AND the Trust Anchor Obligations before I can accept the invitation.# Upon completing Step 3, I should be able to send a Claim Request back to the inviter which requests the Inviter issues a Public Claim of a Trust Anchor Connection to the Sovrin Ledger. NOTE: This Claim Request will be interpreted by the Inviter as my acceptance of the invitation. (denial will be covered in a later story)(Inviter then sees my acceptance and writes a Public Claim of our Trust Anchor Connection to the Ledger, covered in SOV-301)(Then the Inviter sends me a message pointing me to the Public Claim of the Inviter's Trust Anchor Connection with me, newly written to the ledger, also covered in SOV-301)After that is done in SOV-301 I need to be able to: # Write a Public Claim to the ledger of my new Trust Anchor Connection with the Inviter.# Send a message to the Inviter pointing them to the Public Claim I wrote of my new Trust Anchor Connection with the Inviter.# If I complete Step 4, all the rest of the steps should happen automatically.All terms are defined in the [Sovrin Trust Framework|https://docs.google.com/document/d/1n6if3-JZw8BaRmxm3B9X5mKj_IZPHLqi_khHFOrY-XA/edit#]"
Answer: 870426.0

User story: "Given I am a Trust Anchor Invitee I need to: 1. Create a proof associating my Trust Anchor DID with my legal Identity"
Answer: 870426.0

User story: "As a group of Stewards and/or Sovrin tech. gov. member I need to be able to: # Invite a new Steward to the network"
Answer: 870426.0

User story: "Give I am a Dependent Identity Owner, I should be able to:1. Instruct my Guardian to grant me control of my Identifiers."
Answer: 870426.0

User story: "Given I am a Dependent Identity Owner (meaning I have a Guardian who controls my Sovrin Identifiers) I should be able to: 1. Instruct my Guardian to transfer Guardianship to another Guardian."
Answer: 870426.0

User story: "Given I am I Trust Anchor and I am creating Indenpendent Identities on Sovrin:1. I need to be able to obtain the Sovrin Identity Owner Agreement form from EVERY Sovrin Identity I createSovrin Identity Owner Agreement: https://docs.google.com/document/d/108RzMIUttXDooJR2CWrXDR-roF3wsk2eHvN-Iwxqq8k/edit#heading=h.s9fy0y2f2m3m"
Answer: 870425.0