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) :          ~+*Unit Test (UT) leader*+: Yacov~    ~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/]~    The latest code coverage report (after the last CR will be merged) for the packages that were introduced and that have code (many packages are just interface declarations or mocks) is the following:  {code:java}  21:05:08 unit-tests_1  | ok   github.com/hyperledger/fabric/core/handlers/endorsement/builtin 0.082s coverage: 100.0% of statements  21:05:08 unit-tests_1  | ok   github.com/hyperledger/fabric/core/handlers/validation/builtin 0.176s coverage: 87.3% of statements  {code}  The code in *core/handlers/\{endorsement, validation}/* deals with the actual implementation of the plugins.   As for files that were added into existing packages:  {code:java}  github.com/hyperledger/fabric/core/endorser/plugin_endorser.go  coverage: 90.8%   :)     github.com/hyperledger/fabric/core/endorser/state.go  coverage: 77.8%  :(    opened FAB-10107  github.com/hyperledger/fabric/core/committer/txvalidator/plugin_validator.go  coverage: 86.4% :|    opened FAB-10109  {code}  These deal with the infrastructure of the plugins, i.e - instantiating them, and passing the peer's dependencies into the plugin itself.     +**********++*Function Test (FVT) leader*+: Yacov   ~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):~   # ~Test Invalid plugin - --FAB-10330--~   # ~Scenario Description Y~   # ~Scenario Description Z~    B.  E2E testcases scenarios (Add one individual jira TASK within this feature Epic for each of these):   Since pluggable endorsement and validation comes in 2 flavors:   # Builtin   # Plugin   And the Builtin one is exercised in all e2e scenarios trivially, just one scenario is needed.   The scenario (----FAB-10051----) would be as follows:    {code:java}   Let E2E be a standard end-to-end scenario that invokes chaincode and queries it to test that transactions have been committed successfully.     - Compile an endorsement plugin, and a validation plugin, and change the peer's config such that they are loaded instead of the builtin plugin.   - Run E2E and if it passed successfully, then declare the scenario to pass successfully, and otherwise declare a failure.  {code}  C.  Other functional testing required:   No other test is needed         +*System Verification Test (SVT) leader*+: [~<USER>   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         Yacov: I don't think there is really anything to test here w.r.t to performance. My gut says that any performance gains we can get via this work are negligible because ECDSA verification and ledger IO should still be the important factor."
Answer: 36947.0