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: "at the end of eyfn we query the peer from org3 to make sure it has the expected state.    We should ideally also query the rest of the peers to make sure they accepted the endorsement that used the peer from org3."
Answer: 231.0

User story: "As a developer, I want to be able to setup the test such that the peer core.yaml and orderer.yaml configuration files are generated based on the values set in the World config."
Answer: 83249.0

User story: "I have seen in FAQ that we can set chaincode input/output visiblity.  h2. Security & Access Control    *Data Privacy and Access Control*:   # How do I ensure data privacy?    A. There are various aspects to data privacy. First, you can segregate your network into channels, where each channel represents a subset of participants that are authorized to see the data for the chaincodes that are deployed to that channel. {color:#8eb021}Second, within a channel you can restrict the input data to chaincode to the set of endorsers only, by using visibility settings. The visibility setting will determine whether input and output chaincode data is included in the submitted transaction, versus just output data.{color} Third, you can hash or encrypt the data before calling chaincode. If you hash the data then you will need to provide a means to share the source data. If you encrypt the data then you will need to provide a means to share the decryption keys. Fourth, you can restrict data access to certain roles in your organization, by building access control into the chaincode logic. Fifth, ledger data at rest can be encrypted via file system encryption on the peer, and data in-transit is encrypted via TLS.         Is there any documentation or sample code for chaincode visibility?.         I have set up fabric network which has two organizations(2 peers in each organization). These two organizations can access/view the ledger data.Then i have added third organization with two peers to the {color:#8eb021}same channel{color}. I do not want this(Org3) organization to see the data shared by org1 and org2. Is encryption the only way to restrict?. How does visibility work in chaincode?. Is this feature still in development?."
Answer: 877264.0

User story: "The mockery mocks look like they are generatable via go generate, but they are not."
Answer: 157.0

User story: "The world currently embeds a Deployment but the lifecycles are really independent. Given the independent lifecycles, there should be a way to provide a deployment to the world and have it perform the steps required to deploy chaincode.    Multiple deployments must be supported to enable install and instantiation of multiple chaincode instances to one or more peers."
Answer: 17129.0

User story: "The line  {code:java}  When I vendor go packages for fabric-based chaincode at <path>{code}  needs to be written and defined for use in the fabric-test/feature behave system tests."
Answer: 20056.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 continue to get questions about the original NCAP doc [http://hyperledger-fabric.readthedocs.io/en/latest/arch-deep-dive.html] not matching the actual Fabric implementation and features in some areas.      We should replace the content with text from the more updated paper:    pointer to paper page  https://dl.acm.org/citation.cfm?id=3190538  or direct pointer to pdf  [https://dl.acm.org/ft_gateway.cfm?id=3190538]    And the paper link at [http://hyperledger-fabric.readthedocs.io/en/latest/whatis.html#acknowledgement] should be updated to use the above URL."
Answer: 858827.0

User story: We need to upgrade to protobuf v1.1.0 eventually (ideally soon).  The way the newer version of protobuf generates the backing structs, it adds new fields, one of which is itself a struct.  Since only types which may be directly compared with '==' and '!=' map be used in maps, updating protobuf creates a number of build failures:    {noformat}  # github.com/hyperledger/fabric/gossip/privdata  gossip/privdata/pull.go:346:28: invalid map key type "github.com/hyperledger/fabric/protos/gossip".PvtDataDigest  gossip/privdata/pull.go:371:18: invalid map key type "github.com/hyperledger/fabric/protos/gossip".PvtDataDigest  # github.com/hyperledger/fabric/gossip/privdata  gossip/privdata/pull.go:346:28: invalid map key type "github.com/hyperledger/fabric/protos/gossip".PvtDataDigest  gossip/privdata/pull.go:371:18: invalid map key type "github.com/hyperledger/fabric/protos/gossip".PvtDataDigest  gossip/privdata/coordinator_test.go:244:29: invalid map key type "github.com/hyperledger/fabric/protos/gossip".PvtDataDigest  gossip/privdata/coordinator_test.go:245:8: invalid map key type "github.com/hyperledger/fabric/protos/gossip".PvtDataDigest  gossip/privdata/coordinator_test.go:321:28: invalid map key type "github.com/hyperledger/fabric/protos/common".CollectionCriteria  gossip/privdata/coordinator_test.go:329:21: invalid map key type "github.com/hyperledger/fabric/protos/common".CollectionCriteria  {noformat}    As a prerequisite to updating proto, we must move these fields to use a different element as their key.
Answer: 68413.0

User story: "There are a number of places in our tests where we assert or need to assert that two protos are equal.  Often this test is after a proto has gone through a round of marshaling and unmarshaling.    Historically, if the proto contained an empty map or slice, these equality tests would fail and required the use of proto.Equal to check equality.    However, protobuf v1.1.0 actually adds a cache field which may be populated differently for even otherwise equivalent messages.  In this case, the equality checks fail.    All of this points toward the need for a uniform way to check proto equality.  A gomega custom matcher seems to fit the bill nicely."
Answer: 623932.0

User story: There's a few things to fix in systemchaincode.rst, like capitalizing "Fabric" and correct use of compound modifiers.
Answer: 99.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: "[http://hyperledger-fabric.readthedocs.io/en/latest/msp.html#best-practices]   * request originator is always doomed to belong to – change _doomed_ to _deemed_   * If a different mapping type of mapping is chosen – remove words _of mapping - redundant?_"
Answer: 420.0

User story: "There should be a simple setup for setting up the network to help eliminate copy pasting of setting up an e2e integration test.  "
Answer: 3109.0

User story: "levelDB supports bloom filters, that can increase performance dramatically.     Can you add bloom filters, bits per key and BlockCacheCapacity in config file, so it is easy to configure them. In many real cases this functionality will be needed. For now the only way to enable them is by forking the source and compile custom Fabric.     In my benchmarks, with 1.7 billion keys, without bloom filters, leveldb can do ~100 get request per second. If bloom filters are enable performance goes up to ~18000 get request per second.    Of course, this consume couple of gigabytes of RAM, in this particular case around 5GB, but we need the performance and the servers have the needed amount of RAM. In the ledger we have more than 5 billion keys."
Answer: 879283.0

User story: "Extend {{ledger.TxSimulator}} interface with {{GetHeight}} method to obtain updated and actual ledger height."
Answer: 879861.0

User story: "Multiple times, proto definitions which do not adhere to the proto style have been merged.    Not following proto style makes our protos inconsistent, and is something we agreed we would follow long ago.    Since reviewers don't seem to notice when the proto style is skipped, we should really have a CI task which enforces and -1s these violations.    The particular conventions which concern me are that:   # Field names are lower_snake_case   # Messages are UpperCamelCase   # Enums are UPPER_SNAKE_CASE"
Answer: 625321.0

User story: "Currently, the chaincode resides in the testdata directories. Ideally, tests should be able to state the path on how to access the chaincode without copying the files or having multiple copies of the same chaincode under integration tests."
Answer: 2718.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, with the marbles_private_data sample chaincode, when a peer who is not    authorized to the private data issues a query for that data, they receive the following 'Error' when this is actually expected behavior.  We should handle this error better and improve the message returned. I'm not sure it should be an error.  'Peer not authorized to private data' or something like that?    ```root@a0233053115d:/opt/gopath/src/github.com/hyperledger/fabric/peer#  peer chaincode query -C mychannel -n marblesp -c '\{"Args":["readMarblePrivateDetails","marble1"]}'   Error: error query chaincode by endorsing: status:500 message:"\{\"Error\":\"Failed to get private details for marble1: GET_STATE failed: transaction ID: 8bc0cf1b23773b11010e1670c8fd8daeb12cce611cbc03167102b9a83e1dd3bd: Private data matching public hash version is not available. Public hash version = &version.Height\{BlockNum:0x6, TxNum:0x0}, Private data version = (*version.Height)(nil)\"}"    root@a0233053115d:/opt/gopath/src/github.com/hyperledger/fabric/peer#```
Answer: 625504.0

User story: The peer CLI clients for connecting to an endorser, admin server, deliver service, or broadcast service use a hard-coded timeout of 3 seconds. This makes the unit tests that expect failures run exceptionally slow. This task updates the peer clients to use new config values "peer.client.connTimeout" and "orderer.client.connTimeout" so that tests can explicitly set a lower timeout value.     Current time to run unit tests locally:    ok github.com/hyperledger/fabric/peer/chaincode 7.987s  ok github.com/hyperledger/fabric/peer/channel 8.639s  ok github.com/hyperledger/fabric/peer/common 6.115s  ok github.com/hyperledger/fabric/peer/node 4.087s     
Answer: 8553.0

User story: "Update BYFN to use V1_2 application capability.    Required for private data collections."
Answer: 2872.0

User story: "The ginkgo test setup should be able to use a kafka based orderer network."
Answer: 8319.0

User story: It's not clear how you can tell that you are using an admin setup or a user setup after using the tool. The output all goes to a directory "user". How do I know that the admin flag worked as expected?
Answer: 884300.0

User story: "The idemix APIs should hide the use of protobufs in its APIs.  It can do this by:  a) adding XXXToBytes and XXXFromBytes functions for all XXXobjects that are returned.  This allows fabric CA to serialize/deserialize these objects over the wire or when persisting them.  An example is the IssuerKey which fabric CA needs to persist.  b) not use any explicit protobuf structs in any of its function signatures, but just define types such as           type IdemixIssuerKey interface{}           func NewIssuerKey(...) (IdemixIssuerKey, error)"
Answer: 884361.0

User story: "Need to be able to specify an output directory for idemixgen"
Answer: 279.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "The [context deadline timeout|https://github.com/hyperledger/fabric/blob/release-1.1/peer/common/peerclient.go#L31] is currently fixed to 3 seconds. In some cases (e.g. when DNS is slow) the connection drops too quickly, so the ability to tune the timeout variable would be great."
Answer: 90550.0

User story: "peers.md could stand some cleanup:   * wording   * grammar   * standardize on em dashes"
Answer: 646.0

User story: "Remove ESCC and VSCC out of systemchaincode.html for v1.2     see FAB-9855"
Answer: 5591.0

User story: "The final edits for identity.md and membership.md are available in master but not in the (current release-1.1 branch). Need to make these available in the v1.1 docs."
Answer: 1077.0

User story: For the sake of more visually obvious patches to the doc files, I propose restructuring all of the doc files so that each sentence corresponds to a single physical line, regardless of the length of the sentence. While a first reaction to that idea is, "Oh, man, that means really long sentences are going to stream off the right end and I have to scroll over to the right to see them," it also means that patches are more focused and localized and reflect *only* the changes.    As it stands now, if one wants to physically wrap lines to not exceed 80 characters, if you, say, add a new sentence in the middle of a lengthy paragraph, then the remainder of that paragraph would have to be refactored and, visually, the change would appear as a wide-sweeping change to a massive hunk of that paragraph, which is misleading.    The "one line per sentence" standard is used by the [Pro Git book at GitHub|https://github.com/progit/progit2], and when I started contributing to that project, I was initially put off by that standard, but it took very little time to appreciate that it was, in fact, the right way to do things. So give it some thought.
Answer: 867270.0

User story: Some of the Markdown files are getting overly long, and make submitting changes to them more difficult as it increases the chances of clashing with someone else's changes – case in point, peers/peers.md is now well over 500 lines long, and could easily be subdivided into logical sections.    Markdown itself apparently does not support a basic "include" directive to support this, but this can be implemented using reST, as you can see in the doc file command_ref.rst, which includes lower-level Markdown files:    .. toctree::   :maxdepth: 1    commands/peercommand.md   commands/peerchaincode.md   commands/peerchannel.md   commands/peerversion.md   commands/peerlogging.md   commands/peernode.md   commands/configtxgen.md   commands/configtxlator.md   commands/cryptogen.md   commands/fabric-ca-commands          
Answer: 886387.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: "Before closing this testplan task, coverage must be reviewed and approved (via upvote or comment) by the epic feature owner and the test leads identified below.    +*Location / Description of*+ docs, APIs, config vars, system configuration (fabric, SDKs, fabric-samples) :    Doc: [https://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html#listing-certificates-information]    API: [https://github.com/hyperledger/fabric-ca/blob/master/swagger/swagger-fabric-ca.json]    CLI: [https://hyperledger-fabric-ca.readthedocs.io/en/latest/clientcli.html]    +*Unit Test (UT) leader*+: [~<USER>    Test coverage maintained above 85% for all packages  {noformat}  ok      github.com/hyperledger/fabric-ca/cmd/fabric-ca-client/command    53.059s    coverage: 89.7% of statements  ok      github.com/hyperledger/fabric-ca/cmd/fabric-ca-server    3.253s    coverage: 91.3% of statements  ok      github.com/hyperledger/fabric-ca/lib    117.582s    coverage: 85.5% of statements  ok      github.com/hyperledger/fabric-ca/lib/attr    0.023s    coverage: 97.9% of statements  ok      github.com/hyperledger/fabric-ca/lib/metadata    0.020s    coverage: 92.5% of statements  ok      github.com/hyperledger/fabric-ca/lib/server    0.023s    coverage: 96.3% of statements  ok      github.com/hyperledger/fabric-ca/lib/spi    0.018s    coverage: 100.0% of statements  ok      github.com/hyperledger/fabric-ca/lib/streamer    0.017s    coverage: 86.4% of statements  ok      github.com/hyperledger/fabric-ca/lib/tcert    0.047s    coverage: 90.7% of statements  ok      github.com/hyperledger/fabric-ca/lib/tls    0.254s    coverage: 87.9% of statements  ok      github.com/hyperledger/fabric-ca/util    2.850s    coverage: 85.8% of statements{noformat}  +*Function Test (FVT) leader*+: [~<USER>   In v1.2 the peer is not well structured for integration tests, therefore we will compensate with expanded Unit tests and E2E tests. Describe function test coverage approach here:    A.  Expand unit testcases beyond traditional UT coverage, for the following integration scenarios that otherwise might be doneusing the ginko framework): Unit tests are considering real (non-mockup) components           Covered via integration/acceptance tests below    B.  Integration/Acceptance testcases scenarios (Add one individual jira TASK within this feature Epic for each of these)   # Testing new Certificates REST API with Postgres FAB-10224   # Testing new Certificates REST API with MySQL FAB-10321    C.  Other functional testing required: N/A    +*System Verification Test (SVT) leader*+: ????   V1.2 System Test Plan (Epic) FAB-????   Covers stress, load, performance, full system integration, resiliency, recover, etc.    Considering this feature, what scenarios are of particular interest and concern:   # Performance on both server and client when a request is made to get a large (>500) number of certificates. Neither client nor server should experience OOM."
Answer: 300294.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: "Detecting trailing args for 'peer version' and print usage to make it follow more conventions."
Answer: 100829.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: "Weekly jobs on below tasks:    Run goAST scan on fabric-ca build for all applicable go packages    Run OWASP dependency check on fabric-sdk-java    Enable vulnerable tests on fabric-sdk-node.     "
Answer: 6816.0

User story: "And get rid of the unnecessary {{.gitignore}} files introduced with FAB-9881."
Answer: 9001.0

User story: "1) We need to describe the steps required to upgrade your network from v1.1 to v1.2    Upgrade procedure:    – Bring all binaries up to 1.2.    – Then enable one 1.2 Capability (through channel config transaction).    ==> Any 1.1 peer that is not upgraded to 1.2 will crash (which is designed behavior).    ==> 1.1 orderers will not crash, though it is recommended that all binaries are brought up to 1.2    2) We should provide an example how to upgrade BYFN i.e.   Checkout v1.1 byfn at 11   Start it up   Checkout v1.2 byfn   Run upgrade steps against all 4 peers, orderer, ...        Contacts:    [~<USER> - can help with the steps to update BYFN    [~<USER> - can help with describing the process required         Existing Upgrade doc is at:    [http://hyperledger-fabric.readthedocs.io/en/latest/upgrading_your_network_tutorial.html]         From Jason Y: It should be pretty simple, basically copying the v1.0-v1.1 instructions, and removing large sections of it.  I had not been planning to provide seed content, but I'm happy to do whatever is needed.    "
Answer: 53005.0

User story: The "peer channel fetch" and "peer chaincode install" commands currently log their success output message at the debug level. This can make certain integration/e2e tests fail unexpectedly if the log level is set to any other level.     It seems natural that the logged message upon success should be at the info level.
Answer: 1355.0

User story: "Instead of FileKeyValueStore, I want users to be able to interact with the application using an HSM. What files should I change to achieve this goal? What should I do in general?     I found the below files that I apparently should change but I don't know where I should specify Pin and libpath and  slot of the HSM.     [ balance-transfer/node_modules/fabric-client/config/default.json ]    [ balance-transfer/artifacts/org1.yaml ]    [ balance-transfer/artifacts/org2.yaml ]"
Answer: 449282.0

User story: "Using the service discovery reference implementation in golang, we should create a CLI to be used by network operators and for testing."
Answer: 46279.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 PTE driver does not return error codes on failure. Example: Chain code installation failure, instantiation failure etc.     Example below: Instantiation failed but no return error code that client can use to break PTE execution.    info: [PTE 0 main]: [getCCID] Nid: 0, chaincode_id: sample_cc_ch1, chaincode_ver: v0    error: [client-utils.js]: sendPeersProposal - Promise is rejected: Error: 2 UNKNOWN: error starting container: API error (503): upstream connect error or disconnect/reset before headers        at new createStatusError (/home/testuser/fabric-sdk-node/node_modules/grpc/src/client.js:64:15)        at /home/testuser/fabric-sdk-node/node_modules/grpc/src/client.js:583:15    error: [PTE 0 main]: [chaincodeInstantiate] channelName(defaultchannel) chaincode instantiation was bad    error: [PTE 0 main]: [chaincodeInstantiate] Failed to send instantiate Proposal or receive valid response. Response null or status is not 200. exiting...    info: [PTE 0 main]: Disconnecting the event hub: n410ceb97be8a4b1498fd24545a4640ec-org1-peer1.stage.blockchain.ibm.com:31003    error: [PTE 0 main]: [chaincodeInstantiate(Nid=0)] Failed to instantiate transaction on defaultchannel due to error:  Error: Failed to send instantiate Proposal or receive valid response. Response null or status is not 200. exiting...        at /home/testuser/fabric-sdk-node/test/PTE/pte-main.js:703:23        at <anonymous>"
Answer: 532448.0

User story: "   {noformat}  Upgrade all Fabric Network Components  (Either some or all at a time - Eventually upgrading all to latest version under system test 1.2)              a) peers              b) channels              c) orderers              d) membership service provider              e) nodesdk client tool              f) javasdk client tool  {noformat}     {noformat}  Enable new features with run-time flags that determine if new functionality (capability level) will be available in certain components.{noformat}"
Answer: 634040.0

User story: From the Hyperledger e-mail discussion group there's been discussion about channel name needing to be all lower case. We could not find that documented anywhere.    "Yes, the channel name must be all lower case. More precisely, it must be less than 250 characters long and match the regular expression: "[a-z][a-z0-9.-]*"    I propose that we update the Helper text on the peer channel create command here [http://hyperledger-fabric.readthedocs.io/en/latest/commands/peerchannel.html?highlight=peer%20channel%20create]         But I know this text is auto-generated.    [~<USER>    Would you know who owns the source for this command and how we can get get it updated?
Answer: 49413.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: "If a CouchDB username has been configured for the peer, enforce authentication for each database within CouchDB.  This can be done with the _security API:    http://docs.couchdb.org/en/2.0.0/api/database/security.html     When peer gets a handle to a CouchDB database, CreateDatabaseIfNotExist() is called to validate that the database already exists, and creates the database if it doesn't already exist.  As part of this initial validation, also call the _security API to set the configured username as a database member.    Need to support several scenarios:   * Newly created database with username credentials configured.   * Username credentials added to peer after db creation.   * Username credentials changed after db creation.   * Username credentials removed after db creation.    Due to the above scenarios, simply re-PUT the db credentials each time CreateDatabaseIfNotExist() is called, rather than attempting to diff and update the list of database members.          "
Answer: 10164.0

User story: "Make `env.Cleanup()` a single call. Record all the db names (that gets created by a test) inside test env and perform clean up on all at the end.    Right now, its not easy to use when someone has to specify all the db names manually  e.g., - https://github.com/hyperledger/fabric/blob/master/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb_test.go#L72    "
Answer: 190392.0

User story: "When installing Fabric Samples & Binaries using the curl command (found in [http://hyperledger-fabric.readthedocs.io/en/latest/install.html]), the couchdb, zookeeper, and kafka images w/ tag *x86_64-0.4.6* are downloaded.    However, in Docker Hub, the most recent version of those images have the tag *x86_64-0.4.7*.  Will there be a change coming?  Please advise.    Advance apologies if this is already a known issue.  I tried searching on JIRA but couldn't find anything.     "
Answer: 638642.0

User story: There is a typo for transaction in testAPIs.sh    I used Hyperledger Fabric in my course project. The sample code is very helpful example in writing my own chaincod. Thank!    diff --git a/balance-transfer/testAPIs.sh b/balance-transfer/testAPIs.sh  index 57673c6..e83a672 100755  --- a/balance-transfer/testAPIs.sh  +++ b/balance-transfer/testAPIs.sh  @@ -170,7 +170,7 @@ TRX_ID=$(curl -s -X POST \          "fcn":"move",          "args":["a","b","10"]   }')  -echo "Transacton ID is $TRX_ID"  +echo "Transaction ID is $TRX_ID"   echo   echo     diff --git a/balance-transfer/typescript/testAPIs.sh b/balance-transfer/typescript/testAPIs.sh  index 63430ad..8447ad2 100755  --- a/balance-transfer/typescript/testAPIs.sh  +++ b/balance-transfer/typescript/testAPIs.sh  @@ -128,7 +128,7 @@ TRX_ID=$(curl -s -X POST \          "fcn":"move",          "args":["a","b","10"]   }')  -echo "Transacton ID is $TRX_ID"  +echo "Transaction ID is $TRX_ID"   echo   echo
Answer: 893265.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: "Recently I am finding solution about how to build docker image of fabric family from source code. But most documents are talking about 'you have to have vagrant first'.    What I want is a non-vagrant and docker only build solution.    Then I found all I want has been implemented in MakeFile.    Still, I could not find verbose document about using MakeFile"
Answer: 893911.0

User story: "in the PTE, the method should be reused"
Answer: 640809.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: "Add package.json file to install node modules in PTE tool, instead of copying the fabric-node-sdk package.json here."
Answer: 358.0

User story: "Currently, when a user of LTE wants to get the resultant TPS (transaction per second), he/she has to calculate that from the generated CSV file.    *Requested Improvement*:   The TPS number should be the part of the console output of running the LTE.   Additionally, a progress bar showing the progress of a test can be very helpful."
Answer: 641498.0

User story: "identity.md could use some cleanup:   * grammar/wording   * fonts   * uniform em dashes"
Answer: 896423.0

User story: "Minor cleanup to fabric_model.rst, functionalities.rst doc files."
Answer: 602.0

User story: "*Scenario:*    I have large sets of data that I need to import into an instance of Hyperledger Fabric in the fastest way possible.         *Current Options:*    *1.* Send a single invocation for each record. This has major overhead issues as each invocation must be signed and validated. (very slow)    *2.* Group records into a bulk string (of say 1000 records), import all 1000 records in a single invocation with multiple calls to `stub.PutState()` in a loop. This option is far better. However, many separate calls to the ledger can still be slow. (In my tests each bulk of 1000 records can take around 5-10 seconds).         *Proposed Solution:*    Calls to `stub.PutState()` should be queued up and called together when the invocation is complete.   OR   A new API method should be added that does the above while leaving the original `PutState()` alone         You can also see the brief original discussion on RC with [~<USER>: [https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=Qg6JNQN59H6iDxZNe]"
Answer: 897790.0

User story: Besides just tweaking some wording, this file contains two different rendering (both wrong) of what should be "em" dashes, which should be represented by three consecutive dashes. It would be nice if everyone settled on that standard.
Answer: 659.0

User story: "In the current release(version 1.1.0), even though that InvokeChaincode called on different channel is essentially a read only transaction, CHANNELWRITERS permission is still needed.  However, there is no related documents to clarify this point, which could cause misunderstanding.    Also, there should be a list of resources using ACL, like endorser/CSCC/LSCC/QSCC etc."
Answer: 898197.0

User story: Minor tweaks to whatis.md:   * spelling fixes   * add some hyperlinks   * correct spelling of "Raft" consensus algorithm
Answer: 1632.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: While distributing private data, the collection configuration is being looked up with the transient store, for each collection name new query is issued, e.g.    {code}   for _, pvtRwset := range privData.NsPvtRwset {    namespace := pvtRwset.Namespace    for _, collection := range pvtRwset.CollectionPvtRwset {     collectionName := collection.CollectionName     cc := common.CollectionCriteria{      Namespace:  namespace,      Collection: collectionName,      TxId:       txID,      Channel:    d.chainID,     }     colAP, err := cs.RetrieveCollectionAccessPolicy(cc)     if err != nil {      logger.Error("Could not find collection access policy for", cc, "error", err)      return nil, errors.WithMessage(err, fmt.Sprintf("collection access policy for %v not found", cc))     }       colFilter := colAP.AccessFilter()     if colFilter == nil {      logger.Error("Collection access policy for", cc, "has no filter")      return nil, errors.Errorf("No collection access policy filter computed for %v", cc)     }       colCP, err := cs.RetrieveCollectionConfigPackage(cc)     if err != nil {      logger.Error("Failed to load collection config package, collection criteria", cc, "error", err)      return nil, errors.WithMessage(err, fmt.Sprintf("collection config package, for %v not found", cc))     }       pvtDataMsg, err := d.createPrivateDataMessage(txID, namespace, collection, colCP, blkHt)     if err != nil {      return nil, errors.WithStack(err)     }       dPlan, err := d.disseminationPlanForMsg(colAP, colFilter, pvtDataMsg)     if err != nil {      return nil, errors.WithStack(err)     }     disseminationPlan = append(disseminationPlan, dPlan...)    }   }  {code}    where for each collection criteria returns same results, therefore no need to repeat query for each collection name and this could be optimized.    {code}     cc := common.CollectionCriteria{      Namespace:  namespace,      Collection: collectionName,      TxId:       txID,      Channel:    d.chainID,     }  {code}    Thus this code could be optimized with respect of query numbers and also additional fact to consider, is possible race condition, where collection config could be update after endorsement, hence it might be a case we are reading configuration which is not relevant for private read-write set in context.
Answer: 9275.0

User story: Since version 1.5, the go tool has allowed package authors to separate internal details from those that are expected by to be user-consumable. This is accomplished by placing internal packages in directories that include "internal" in the name.    We should restructure the fabric repository to explicitly place our implementations under fabric/internal and only leave the packages we expect users to consume outside of that root.    Not only will this help make it clearer to users what they should and should not use, it will help us as with semantic versioning.    /cc [~<USER>
Answer: 899077.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: "While, technically, the fabric-samples directory should not be responsible for separately downloaded bin/ and config/ directories, the precedent has been set, so this repo should ignore the config/ directory."
Answer: 14736.0

User story: "In the introduction, when discussing the advantage of Fabric being able to use non-domain-specific languages for writing chaincode, a link to Solidity would be useful just to compare and contrast."
Answer: 2186.0

User story: Docs file prereqs.rst contains a :ref: to a non-existent label "binaries"; simply replace that reference with a verbatim rendering for now to get rid of the diagnostic.
Answer: 2199.0

User story: "Current docs build generates:    {{/home/<USER>hyperledger/fabric/gerrit/docs/source/enable_tls.rst:138: WARNING: undefined label: upgrade-vendored-shim (if the link has no caption the label must precede a section header)}}    This is because that label no longer exists in the doc file upgrade_to_one_point_one.rst. Simple solution is to simply remove that reference until the rest of the docs are updated."
Answer: 2216.0

User story: The information in this doc: [http://hyperledger-fabric.readthedocs.io/en/latest/pluggable_endorsement_and_validation.html]    Really belongs in a few separate docs. Suggest combining it with some of the information in [http://hyperledger-fabric.readthedocs.io/en/latest/endorsement-policies.html] with some of the higher level info in pluggable endorsement to create an "Endorsement" key concept doc. Then take material from both docs and create an "Operations Guide" doc for endorsement (covering regular endorsement as well as pluggable endorsement, depending on what's still relevant from the older "endorsement" doc.    Then let the rest live in an "Architecture Reference" doc on endorsement.
Answer: 900018.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: To ensure nobody else tries to write test cases using the deprecated (still exists in v1.2 but must be removed prior to v1.3) and unreliable peer event hub code in fabric, let's remove the deprecated options the PTE tool, scripts, and clean up the instructions in PTE Readme.     * **eventOpt**: event hub options {color:#FF0000}[REMOVE "hub"]{color}   * **type**: event service type, default: Peer {color:#FF0000}[CHANGE default from Peer to FilteredBlock]{color}   *     **FilteredBlock**: filtered block event service at channel level {color:#FF0000}[REWORD to "efficient option, delivers filtered events (per channel) for each block or transaction"]{color}   *     **Channel**: events at channel level {color:#FF0000}[CHANGE description to "basic option, delivers full events (per channel) for each block or transaction"]{color}   *     **Peer**: events at peer level {color:#FF0000}[REMOVE LINE]{color}   * **listener**: event listener, default: Transaction {color:#FF0000}[CHANGE default from Transaction to Block]{color}   *     **Transaction**: PTE registers a transaction listener to receive a registered transaction event. This is the default event listener. {color:#ff0000}[CHANGE entire description to "one event per transaction"]{color}   *     **Block**:{color:#ff0000} {color}PTE registers a block listener to receive every block event on all channels. PTE will parse the received block event for the transactions sent. The block listener option, {color:#ff0000}applies to tranMode CONSTANT only [REMOVE restriction].   [And CHANGE entire description to "one event per block"]{color}   *     **None**: PTE will not register any event listener. {color:#FF0000}[REMOVE line]{color}   * **timeout**: event timeout, {color:#ff0000}[REMOVE restriction: "applied to the transaction listener only",{color} unit ms, default: 120000 ms
Answer: 9995.0

User story: "PTE supports side DB.    references:    FAB-8718 Finalize Side DB - private Data    FAB-7593 Side DB - Local collections    Supports marbles02 private chaincode, [github.com/hyperledger/fabric-test/fabric-samples/chaincode/marbles02_private/go|https://github.com/hyperledger/fabric-samples/tree/master/chaincode/chaincode_example02], with its APIs: initMarble, readMarble, and readMarblePrivateDetails"
Answer: 46336.0

User story: "PTE hyperledger fabric service discovery.    References:    https://jira.hyperledger.org/browse/FAB-8779    [https://docs.google.com/document/d/1zP04PKay4FN0tKYjHUSanyfK9b94rtYvC9MDSKGeSSE/edit]    [https://www.youtube.com/watch?v=yVSntuM5Enw]"
Answer: 72345.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: "Before closing this testplan task, this must be reviewed and approved by this epic feature owner and the Test Prime (identified below), to agree on appropriate coverage for each test phase.    +*Location / Description of*+ docs, APIs, config vars, system configuration (fabric, SDKs, fabric-samples) :         +*Unit Test (UT) leader*+: ????    Automated unit tests are merged in repo, as go tests or otherwise part of build/verify jenkins jobs.   Code coverage tracked in Jenkins: [https://jenkins.hyperledger.org/view/Daily/job/fabric-unit-test-coverage-daily-master-x86_64/]         +***+*+*Function Test (FVT) leader+*: ????   In v1.2 the peer is not well structured for integration tests, therefore we will compensate with expanded Unit tests and expanded E2E tests using ginkgo. Describe function test coverage approach here:    A.  Expand unit testcases beyond traditional UT coverage, for the following integration scenarios that otherwise might be done using the ginko framework):   # Scenario Description X   # Scenario Description Y   # Scenario Description Z    B.  E2E testcases scenarios (Add one individual jira TASK within this feature Epic for each of these):   # Scenario Description X   # Scenario Description Y   # Scenario Description Z    C.  Other functional testing required:   # Method/Tool, and Scenario Description   # Method/Tool, and Scenario Description   # Example: ginkgo (future availability). Description xyz. Untestable in v1.2 ; an identified test coverage gap.         +*System Verification Test (SVT) leader*+: ????   V1.2 System Test Plan (Epic) FAB-????   Covers stress, load, performance, full system integration, resiliency, recover, etc.    Considering this feature, what scenarios are of particular interest and concern:   # Scenario Description X   # Scenario Description Y   # Scenario Description Z"
Answer: 901171.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 that the "-m <mode>" option for byfn.sh is deprecated (not the entire mode, just the "-m" part", get rid of any remnants of that in the documentation.
Answer: 4692.0

User story: "Test for CouchDB indexing with large amount of transactions in network. Will use PTE to drive."
Answer: 98801.0

User story: "Some cleanup including handling of chaintool download."
Answer: 902917.0

User story: "For convenience, add an appropriate .gitreview file to fabric-samples to more quickly allow access to Gerrit."
Answer: 2799.0

User story: "The :doc: reference to configtxgen is broken, since it should refer to the commands subdirectory."
Answer: 2848.0

User story: "Should add a components struct and world struct which configures the setup for the test runs."
Answer: 112249.0

User story: Bold markup doesn't work well inside a string, such as "**anchor peer**s".
Answer: 59136.0

User story: From the Hyperledger email chat (rday)    *[https://lists.hyperledger.org/g/fabric/message/3566?reply=1]*    just noticed that "orderer" is not mentioned here:    *[http://hyperledger-fabric.readthedocs.io/en/release-1.1/command_ref.html]*  **
Answer: 651744.0

User story: "Remove references to bddtests directory."
Answer: 111744.0

User story: "In `core/endorser/endorser.go`, after simulating the transaction and collecting the read/write set, we call the endorser system chaincode (ESCC) to endorse the proposal response. However, to `endorseProposal()`, we pass the released `transaction simulator` object. Hence, an error would occur if we try to use this txsim.     Till now, default ESCC is not accessing the ledger. With a pluggable ESCC (static – [http://hyperledger-fabric.readthedocs.io/en/release-1.1/systemchaincode.html] ) and dynamic (the one that is being added to v1.2), the ESCC may access the ledger.     Hence, it would be better to create a `transaction simulator` and pass it via `endorseProposal()`."
Answer: 907460.0

User story: "every para is a single line, impossible to edit in many tools."
Answer: 404.0

User story: "Time to tidy up the whatis.md file, including fixing grammar, sentence structure, and so on."
Answer: 2984.0

User story: In the section "What's happening behind the scenes?"; there are these two steps    ...    - A chaincode - **chaincode_example02** - is installed on ``peer0.org1.example.com`` and   ``peer0.org2.example.com``    ...  - A query is sent to ``peer1.org2.example.com`` for the value of "a". This starts a   third chaincode container by the name of...      Since the chain code is never installed on  peer1.org2.example.com. The query should return an error message containing " cannot retrieve package for chaincode mycc/1.0"
Answer: 114371.0

User story: "Improve logging for state and history database rebuild, so that when entire database is being rebuilt administrators can understand progress."
Answer: 602558.0

User story: "there are multiple FAQ documents, we only need one."
Answer: 1105.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: "wrappers/*.md show up in sphinx error mesages as missing from TOC. These are actually not intended ever to be included in docs directly as they are source for generated help text."
Answer: 115250.0

User story: In docs/source/build_network.rts, there should be no space in the option "-- cafile".
Answer: 5409.0

User story: "Sharon asked if we could add a list of steps in each tutorial at the top of the tutorial - sort of like I have done for the CouchDB tutorial-  https://gerrit.hyperledger.org/r/#/c/20469/          "
Answer: 927173.0

User story: Given that the byfn.sh script has been stripped of its references to the deprecated "-m" mode flag (not the option, just the flag), remove those references from the BYFN docs page as well.
Answer: 5604.0

User story: "If these are typos under docs/source/:    {{commands/peernode.md:peer node start --peer-node-chaincodedev}}  {{wrappers/peer_node_postscript.md:peer node start --peer-node-chaincodedev}}    I can fix them, just need confirmation that they're typos."
Answer: 5700.0

User story: "Some docs – whether they're in the TOC or not – are out of date or irrelevant. We need to find these and delete them (or update them). For a start, it will be preferable to focus on docs that are not in the TOC."
Answer: 891691.0

User story: There is nothing in the docs directory that makes any reference to the docs file "install_instantiate.rst", so it should be deleted.
Answer: 4860.0

User story: "Currently is Org1 creates a channel, it generates a .block file like mychannel.block. If it wants Org2 to join the channel, the file has to be sent offline to Org2. Org2 then uses the block file to join its peer to the channel.    The offline mode of transporting the file can be eliminated if the Org2 peer connects to the orderer using an environment variable and fetches the genesis block of the channel."
Answer: 910918.0

User story: The text "The configuration block that initializes a blockchain network or channel" sounds not very clear. How about changing it to " The configuration block that initializes the ordering service".    [1]http://hyperledger-fabric.readthedocs.io/en/latest/glossary.html#genesis-block
Answer: 14834.0

User story: "txsim acquires a shared lock on the stateDB which restrict block commits, i.e., commiting valid write-sets to the stateDB. Hence, we should close txsim as soon as the tx is simulated and the rwset is collected. Definitely before gossip dissemination, we must release the shared lock. "
Answer: 8001.0

User story: "The document still has an instruction about bddtests here (http://hyperledger-fabric.readthedocs.io/en/latest/dev-setup/build.html#running-behave-bdd-tests).  FAB-9027 has removed bddtests from fabric.  To follow the change, the document should also be removed.  "
Answer: 25767.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: Today in OTE producers and consumers, there are places where errors occur when attempting to send or receive transactions or when establishing grpc connections. Sometimes we print an error log and continue, and other times it panics and exits. We would like to introduce an error handling routine which could be called from all locatiions and it would:   * optionally collect more data immediately by executing bash commands using something like the existing ote.go func executeCmd() to run 'df' or 'free', for example, or exec into a docker container to collect and display logs, i.e. 'docker logs --tail 100  orderer3.example.com'   * optionally panic (and if no panic, then just print the error string and any collected data in a log instead of in a panic message string).    Here is a proposal for a function that can be called whenever there is an error log to be printed or a panic/abort action needed - optionally (in both cases) with more data collection:    ```   func handleError(outputStr string, shouldPanic=false, shouldCollectData=false, ordNum=0) \{   // ...Implemention details...   if shouldCollectData    \{      cmd := fmt.Sprintf("docker exec -ti df && free")      cmd += fmt.Sprintf(" && docker logs orderer%d.example.com", ordererIndex)      outputStr += executeCmdAndDisplay(cmd) // (we must revise this function a bit) }      if shouldPanic      \{ panic(outputStr) }      else      \{ logger(outputStr) }    }   ```    For example, in startConsumer(), when setting up a connection, a function call might look like this:    \{\{(*consumerConnP), err = grpc.DialContext(ctx, serverAddr, dialOpts...)   if err != nil \{   handleError( Sprintf( fmt.Sprintf("Error on client %s invoking Deliver() on grpc connection to %s, err: %v", myName, serverAddr, err)),   true,   true,   ordererIndex)   }}}     
Answer: 661362.0

User story: "Current output of each OTE test shows the STDOUT logs from runote.sh, as well as one (or two, when errors) other copies of the entire stdout stream (without newlines, so they are not easily readable). I think these are all coming from 3 places, and were added at different times. We should eliminate the unnecessary duplication:    1. this line in fabric-test/tools/OTE/runote.sh (when the CI picks up this after it is wrapped by python into an xml file):    {code:java}  docker cp -a OTE:/opt/gopath/src/github.com/hyperledger/fabric/OTE/ote.log ./logs/$\{TESTCASE}.log  {code}       2 & 3. these lines in fabric-test/regression/daily/orderer_ote.py:    {code:java}   print(result)   logfile.write(result)   self.assertIn(TEST_PASS_STRING, result)  {code}      "
Answer: 661403.0

User story: "incorporate the fabric digest paper"
Answer: 6571.0