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: "Write detailed unit tests that simulate the usage of {{Registry::makeDataGraph}} and DataUnitMap by SuperTask preflight.    These should cover simulated versions of all steps currently in the HSC pipeline, using the {{ci\_hsc}} test database, and explore several common user expressions."
Answer: 485032.0

User story: "Implement {{addDataUnit}} and/or other methods for adding concrete DataUnit instances in SqliteRegistry.    This is tricky because it needs to account for how to ensure join tables between DataUnits are updated as well (i.e. should adding a Visit add the overlaps between that Visit and *all* existing SkyMaps?).    This will probably require some additions to the Registry interface.  Adding methods/arguments that depend on specific concrete DataUnits is fine for base Registry/SqlRegistry, but we should try to implement these in terms of more generic methods that must be implemented by new Registry subclasses    Unit tests for this ticket should include inserting all concrete DataUnit types.  "
Answer: 485034.0

User story: "Implement the {{associate}} and {{disassociate}} methods in SqliteRegistry."
Answer: 281992.0

User story: "Implement the {{makeRun}}, {{updateRun}}, {{addQuantum}}, and {{markInputsUsed}} methods (and any needed getters) on SqliteRegistry, delegating to base classes as appropriate."
Answer: 283350.0

User story: "Implement the {{addDataset}} method on SqliteRegistry, delegating to SqlRegistry as appropriate, on the assumption that the producer and/or run objects being passed are already present in the Registry.    Unit tests for this issue should include composite Datasets."
Answer: 281991.0

User story: "Implement the {{registerDatasetType}} method on SqliteRegistry, delegating to SqlRegistry as appropriate.    If easy to do, also implement it in LimitedRegistry; we don't have an obvious use case for it, but we don't have a reason not to included it in LimitedRegistry's capabilities."
Answer: 281992.0

User story: "Add unit tests for composite Datasets to initial Butler Registry (DM-12640)."
Answer: 485043.0

User story: "Concrete Registries should support initialization from a YAML file."
Answer: 485050.0

User story: "Verify the installation instruction of the Kubernetes 1.8.3 install on the VM infrastructure, making any adjustments to the OpenStack install instructions and noting any differences in the installation instructions.  This is a prelude to installing on hardware to discover any special issues or cases may run ito."
Answer: 48693.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 implentations should be split into the following class hierarchy:    *  Registry (ABC):  *  SqlRegistry (ABC, inherits from Registry)  *  (possibly) SqliteRegistry (concrete, inherits from SqlRegistry)    Going forward, we will expect many more subclasses of SqlRegistry in particular, though we may have to further split the SqlRegistry interface to account for differences between Registries that use the common schema directly vs. those that implement it via views.    Much of the work on this ticket is to defines the roles of these different classes, and hopefully minimize the amount of work necessary to make a new SqlRegistry subclass for a different DBMS.  Because we won't actually be doing that now, we can't expect to make the division of responsibilities perfectly future-proof."
Answer: 155435.0

User story: "Write up instructions on how to install Kubernetes 1.8.3 on Openstack for a master node and two worker nodes.   Also include instructions on how to install a local registry and how to verify the local registry is working.      This will later  be used by the admin create Puppet scripts to do this installation."
Answer: 4175.0

User story: "We are no longer requesting correct scope for the OAuth parms."
Answer: 1474.0

User story: "Write a series of steps that allows us to test how to install Kubernetes on OpenStack consistently.   This includes deploying a Kubernetes master node, and a couple of worker nodes in the cluster.  Also install and verify a local registry."
Answer: 11.0

User story: "The header dialog should be modified so the content updates as the users clicks on the image displayed, or goes through the extensions.  It no longer should call the server.  It should use the plot.headerAry object which contains all the header locally."
Answer: 427746.0

User story: "(This ticket has evolved considerably from its initial content; I'm rewriting the description rather late in the implementation to make it more accurate and provide more reasonable stopping criteria).    Put together a set of scripts for populating Gen3 Registry databases from Gen2 data repositories, with a focus on being able to generate a Registry test dataset from ci_hsc.    This will have a few limitations relative to the more full-featured script we'll need for converting more important Gen2 repositories:   * No Datastore/StorageInfo content will be written yet (just Registry itself).   * Only HSC data will be supported.   * We'll assume a 1-1 relationship between Exposures and Visits.   * We will not try to convert calibration repositories.   * No spatial join tables will be populated.   * All entries in parent repos will be included in the Collections created for their children, rather than trying to limit this to just the relevant DataUnits/DatasetTypes."
Answer: 240330.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: Write functions/classes that convert Registry content from SQL to YAML and back, assuming the SQL schema is created separately.    The YAML format should be designed with the expectation that it will be used  as both:  *  the internal representation of a limited Registry (possibly nested in a file that also contains Butler and Datastore configuration)  *  a format ("the" format?) for transfers between Registries.    This should use SQLAlchemy as much as possible, but target SQLite specifically when necessary.  When interfaces that would allow different future specializations for other RDBMs are obvious, they should be added, but this should not be considered a focus at this point.    The SQL->YAML converter *should* be something usable by all future SQL Registries as a way to dump their output.  We do not expect the YAML->SQL converter to work for all future Registries (as some will expose the common schema via views, or need to rewrite IDs on import), but it will be used by those included in the Minimal Gen3 Butler deliverable.
Answer: 485097.0

User story: "Add class[es] and/or function[s] that generate {{CREATE TABLE}} and {{CREATE VIEW}} statements that construct the full Registry SQL schema.    This should use SQLAlchemy as much as possible, but target SQLite specifically when necessary.  When interfaces that would allow different future specializations for other RDBMs are obvious, they should be added, but this should not be considered a focus at this point.    Considerable work on this has aleady been done in the {{butler_prototype}} repo (on DM-12371), but will need to be extended to include the full schema after that has been defined."
Answer: 281885.0

User story: Implement {{DataUnitTypeSet::pack}} (or {{DataUnitTypeSet::hash}}), including any additions to concrete DataUnit classes needed to support it.    The simplest approach would be to have each DataUnit type declare the maximum number of bits or bytes its "value" can consume and define a mechanism for packing it.  This can be Camera- or SkyMap-dependent, however, it might make sense to find a way to delegate the packing to these objects.  There is real value to minimizing the packed size, especially for DataUnit combinations that will be used to label Catalog datatsets, as we would like to be able to use the same mechanism to define Source/Object IDs by packing the DataUnit label with an autoincrement ID and still have the result fit in 64 bits.    An alternative is to use a hash function (see SHA512 approach in DM-12371).  While that is convenient, we do not (currently) have a mechanism for dealing with collisions, and if we want to use this packing for Source/Object IDs being able to "unpack" in the future (given a DataUnitTypeSet) would be highly desirable.    Decide the best approach (or both) and implement it.
Answer: 103776.0

User story: "Implement Python QuantumGraph class as described in DMTN-056."
Answer: 485111.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: Implement Python Quantum class as described in DMTN-056.    Quantum's input collections must be able to hold multiple equivalent DatasetRefs corresponding to different Collections, in order to support the comparison-SuperTask use case as described in "Running Comparison SuperTasks" in DMTN-056.    Beyond this, the exact behavior of Quantum's input and output containers should not be considered set in stone by DMTN-056.  We probably want to be able to index first by DatasetType and then obtain a collection of DatasetRefs with that type, but whether that collection is a sequence or mapping is TBD.  We probably shouldn't consider this fixed until after we see how the containers are actually used by some concrete SuperTasks.
Answer: 283275.0

User story: "Implement Python Run class as described in DMTN-056."
Answer: 283282.0

User story: "Implement as described in DMTN-056 after preflight redesign (e.g. DatasetLabel and DatasetHandle are merged into DatasetRef)."
Answer: 283282.0

User story: "Implement as described in DMTN-056.    Needs to be comparable/hashable on name.    May want to consider a global cache of all instances, with a construction mechanism that returns existing objects when possible (and verifies consistent DataUnit types)."
Answer: 175398.0

User story: "Implement as described in DMTN-056.    Will require an expand-and-topological-sort algorithm (evaluate the one used on DM-12371)."
Answer: 281894.0

User story: "Generating concrete classes from authoritative docs (if machine readable) is okay, but not necessary, and should not degrade code readability or documentation.    Machine-verifying concrete classes against authoritative docs (if we don't generate them) is also nice, but also not necessary.  Might be a good way to write unit tests.    Should use SP estimate to strictly time-box effort spent generating/machine-verification."
Answer: 103785.0

User story: "Implement and unit-test {{DataUnit}}.    All concrete DataUnits should:    *  represent their tables  *  represent required and optional relations  *  be generated by {{Schema}} from the {{YAML}} configuration  *  be immutable"
Answer: 226144.0

User story: "Generating concrete classes from authoritative docs (if machine readable) is okay, but not necessary, and should not degrade code readability or documentation.    Machine-verifying concrete classes against authoritative docs (if we don't generate them) is also nice, but also not necessary.    Should use SP estimate to strictly time-box effort spent generating/machine-verification."
Answer: 485126.0

User story: "Implement and unit-test StorageClass base/meta class.    Involves implementing {{StorageClass::assemble}} (when needed), but not actual persistence."
Answer: 142467.0

User story: "RFC the proposal from DM-12620 and update as requested by stakeholders."
Answer: 426070.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: "Describe and document the planned Registry SQL schema.  Will start as as a technote (with as much content as possible added to and extract from the YAML file in daf_butler), and probably move to a middleware LDM in the future (after RFC)."
Answer: 267661.0

User story: "Turn lessons learned from discussion between [~<USER>, [~<USER> and [~<USER> into a proposal for how to label and relate all raw and derived calibration products, discuss and adapt with [~<USER>.    Output should be documented in agreed authoritative form (from DM-12617)."
Answer: 485170.0

User story: Define the {{StorageClasses}} (see DMTN-056) we expect to support.    Start with Storages supported by Gen2 Butler, add specializations for major composites.    Can use "generic" (e.g. {{pickle}}, {{afw::table::io}}) {{StorageClasses}} for objects that have no components and no slicing.    Output should be documented in agreed authoritative form (from DM-12617).
Answer: 253302.0

User story: "Decide how we document/control the {{DataUnits}}, {{StorageTypes}}, and additional metadata tables all {{Registries}} are expected to support (as currently described in DMTN-056).    *  Probably something git-controlled, or perhaps MagicDraw.  *  rST/tex document would be easiest to consume.  *  YAML or some other structured, machine-readable form easier to maintain.    It should include describing a formal process for changes.    This ticket entails gathering opinions and (if needed) writing an RFC."
Answer: 485178.0

User story: "For interactive QA drill-down, especially when investigating repeatability metrics, enable a simple plot to quickly scroll through the individual visit-level sky plots of the visits that went into a particular coadd region.  "
Answer: 21520.0

User story: "Use SQLAlchemy ORM to develop a minimal butler Registry. It should support everything except, subsetting/merging, transfers, general query and graphs.    Can share a lot of code with DM-12371 and will be used to decide which of ORM or Core is better for SQL based registries."
Answer: 104007.0

User story: Following DM-12117 ("repositoryCfg.yaml input root not backwards compatible") and DM-12595 ("Failure to load configs when processing HSC data"), check that the solutions adopted are compatible and working, especially for getting the calib root.
Answer: 514386.0

User story: "{{lsst-dev01}} has access to all the GPFS filesystems available to the Verification Cluster (ie, as documented at https://developer.lsst.io/services/verification.html#verification-gpfs). However, if you didn't already know that, you wouldn't discover it by reading https://developer.lsst.io/services/lsst-dev.html. Please cross-link this documentation appropriately."
Answer: 510408.0

User story: "If a user has been idle longer than some threshold, terminate the container."
Answer: 2895.0

User story: "Once the Flask based API is deployed and jointcal data is flowing to SQuaSH we can finally enable jointcal visualization in the SQuaSH Monitor app."
Answer: 223223.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: "Draft a initial version of the test case specification DRP-00-05 in LDM-534.  "
Answer: 25933.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: "Deployment of the SQuaSH RESTful API, this includes the api, nginx and cloud sql containers and kubernetes configuration.    The production URL: https://squash-restful-api.lsst.codes    The demo URL: https://squash-restful-api-demo.lsst.codes"
Answer: 75436.0

User story: "[~<USER> and [~<USER> found a few bugs in jointcal's constrained models that were causing cholmod factorization failures and/or improper fits. I need to implement those changes before doing the meas_mosaic comparison."
Answer: 10192.0

User story: "After some research {{flasgger}} seems to be a good option for documenting the SQuaSH REST API based on Flask    * https://github.com/rochacbruno/flasgger    it conforms with the OpenAPI 2.0 specification and potentially will support OpenApi 3.0 soon.    * http://idratherbewriting.com/learnapidoc/pubapis_openapi_tutorial_overview.html  "
Answer: 41818.0

User story: "Following adoption of RFC-378, make lossless FITS compression the default."
Answer: 200.0

User story: "Add the TPV projection to Firefly.    Steps:  * Trey will modify the infrastructure to recognize the projection.  * [~<USER> will add the projection algorithm in the JavaScript "
Answer: 343046.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: "Remove daf::base::Citizen and all use of it.    I'm calling this a SciencePipelines ticket since the vast majority of the usage is in afw."
Answer: 857573.0

User story: "Use Junk list from Matsuoka-san to validate CompareWarpAssemble"
Answer: 26332.0

User story: "Write up a report (technote?) about CompareWarpAssemble. Include:  * How it works  * Evaluation of Performance  * Recommendations"
Answer: 296801.0

User story:   {code:java}  [<USER>lsst-dev01 0001]$ desstat        ID T PRJ PIPELINE        CAMPAIGN       RUN                         BLOCK                          SUBBLOCK        STAT (H/P/R/T)    OPERATOR RUNSITE                         ================================================================================================================================================================    661815   TST hscrc           MDEV           Ht9813_r3p10                drp-patch                      pipelines       (0/0/73/79)       <USER>lsstdev    666200   TST hscmini         MDEV           Ht0_r3p25                   patch                          blockmngr       RUN               <USER>lsstdev    666221   TST hscmini         MDEV           Ht8766_r3p28                processccd                     0006            RUN               <USER>lsstdev  {code}    where it says "patch" should be "drp-patch"
Answer: 4321.0

User story: "Last night's release failed running {{run-rebuild}}.  The cause was {{validate_drp}} tests failing.    https://ci.lsst.codes/job/release/job/run-rebuild/377/artifact/lsstsw/build/validate_drp/tests/.tests/pytest-validate_drp.xml.failed    This was almost certainly caused by the merger of https://github.com/lsst/validate_drp/pull/60 yesterday."
Answer: 27402.0

User story: "The code in {{validate_drp}} was ported to use {{verify}} in DM-12253, but that did not include porting the documentation.    This ticket is to update documentation in {{validate_drp}} for API changes as well as general docstring cleanup."
Answer: 26339.0

User story: "* Improve Qserv container version management: use tag for Qserv container (produced with git describe (--parent?))   * Build run-kubectl container at runtime with a given version or install kubectl   * What about qserv/qserv:dev container?   * add qserv_deploy to qserv_distrib?   * Try to speed up the build... (reduce container image size)"
Answer: 390488.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 purpose of this ticket is to ask if DM should consider whether the float[6x32] for the characterization parameters for variability is of adequate size to express the additional timescales and depths covered by all possible Special Programs observing strategies. This study might be similar to e.g., DMTN-049 for photometric redshifts included in the DRP Object catalog.    The nominal deadline has been set to 1.5 months prior to the expected call for Special Programs white paper proposals, but need not be resolved by then. Additional context for this ticket can be found in Section 4.6 of the DMTN study on DM and Special Programs, available at https://dmtn-065.lsst.io/  "
Answer: 982971.0

User story: The purpose of this ticket is to clarify whether Object.prv_inputID in the database schema will identify whether an Object is an externally provided coordinate.    For clarification, Section 4.6 of DMTN-065: _"The DMAD specifies that externally defined targets can be incorporated into the Objects catalog (Section 3.2.5), and this may be a particular interest to Special Programs. It is unclear how such targets will be identified or flagged as such in the database schema, and whether we need to add an element for this. Currently, the Object database contains an element prv_inputId which is an integer, and is described as the ”Pointer to prv_InputType. Indicates which input was used to produce a given object.” Is that all we need?"_    All we need to close this ticket is to verify that a (DIA)Source and (DIA)Object that is associated with an externally-provided coordinate has some kind of catalog flag – whether or not this is prv_inputId, exactly how the association is done, and whether externally-provided coordinates are stored as Objects is secondary (I can update the text of DMTN-065 to reflect the answer".    The nominal deadline has been set to 1.5 months prior to the expected call for Special Programs white paper proposals, but need not be resolved by then, as this particular question is not limited to the context of Special Programs. Additional context for this ticket can be found in Section 4.6 of the DMTN study on DM and Special Programs, available at [https://dmtn-065.lsst.io/]          
Answer: 189737.0

User story: The purpose of this ticket is to confirm that the minimum number of "science proposals" that can be optimized by the scheduler, nSciProp = 6 from OSS-REQ-0027, is not too low, given that some proposed mini-surveys might have quite complicated observing strategies.    The nominal deadline has been set to 1.5 months prior to the expected call for Special Programs white paper proposals, but need not be resolved by then. Additional context for this ticket can be found in Section 4.3 of the DMTN study on DM and Special Programs, available at https://dmtn-065.lsst.io/  
Answer: 160859.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 purpose of this ticket is to figure out whether and how auto-triggering of alternative data processing recipes for Special Programs can be supported by the DM system, and if so, how many different pipeline configurations could DM support and how will the need for a specific kind of processing be communicated from the OCS to DM pipelines. If it can't be, a change request on DMS-REQ-0320 might be needed to down-scope.    The nominal deadline has been set to 1.5 months prior to the expected call for Special Programs white paper proposals, but need not be resolved by then. Additional context for this ticket can be found in Section 3.3 of the DMTN study on DM and Special Programs, available at https://dmtn-065.lsst.io/  "
Answer: 1220778.0

User story: "This ticket is to implement the final change from RFC-397. I've tweaked the wording slightly here to clarify the single/multiple inheritance point.    This is the replacement version of the section of the python style guide about {{super()}}:    {code}  `super` MAY be used with care to call inherited methods    Python provides `super()` so that each base class’s method is only called once. Using `super()` ensures a consistent Method Resolution Order, and prevents inherited methods from being called multiple times.    In Python 3, `super()` does not require naming the class that it is part of, making its use simpler and removing a maintenance issue.    The trickiest issue with the use of `super()` is that, in the presence of multiple inheritance, there is no way for a class to know for certain which inherited method will be called.  In particular, this means that the calling signature (arguments) for all versions of a method must be compatible.    As a result, there are a few argument-related caveats about the use of `super()` in multiple inheritance hierarchies:    * Only pass `super()` the exact arguments you received.  * When you use it on methods whose acceptable arguments can be altered on a subclass via addition of more optional arguments, always accept `*args`, `**kw`, and call `super()` like `super().currentmethod(alltheargsideclared, *args, **kwargs)`. If you don’t do this, forbid addition of optional arguments in subclasses.  * Never use positional arguments in `__init__` or `__new__`.  Always use keyword args, and always call them as keywords, and always pass all keywords on to `super()`.    To use `super()` with multiple inheritance, all base classes in Python's Method Resolution Order need to use `super()`; otherwise the calling chain gets interrupted.  If your class may be used in multiple inheritance, ensure that all relevant classes use `super()`, including documenting requirements for subclasses.    Following these guidelines for single inheritance hierarchies, will let them be extended to multiple inheritance with minimal difficulty.  {code}"
Answer: 199381.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: "Fork eotest package and port to py3, and then make PR to upstream"
Answer: 25959.0

User story: "Rebuild spawner options form without needing to redeploy Hub."
Answer: 5644.0

User story: "In accordance with documentation in DM-10360, new statistics for Object and Source tables need to be generated for this new dataset for KPM30 tests. "
Answer: 233543.0

User story: "Copy TS3 data from SLAC/BNL to lsst-dev for use with obs_auxTel. Should be put in {{/datasets}}.    Sensor is 098."
Answer: 16044.0

User story: "The auxiliary telescope is coming online surprisingly soon. We also now know for sure which sensor it will be using. It is therefore prudent to create the obs_package for this now, so that we can start looking at lab data taken with this sensor in order to become intimately acquainted with it before it goes on sky.    This work can either be done by stripping down obs_comCam, or rebooting the somewhat-abandoned obs_ts3 work."
Answer: 139948.0

User story: "Now that TE1 is calculated on the master branch of {{validate_drp}} but not included in the release metrics.  This causes a {{KeyError}} when I run {{reportPerformance.py}} on JSON files produced with a master version."
Answer: 2610.0

User story: "This issue needs research. It is currently possible from CDS if there is a standard. Research and implement the ability to create a list of HiPS repositories.    The service is documented in section 5.2 of the attach HiPS pdf.    The development includes,   * send query to HiPS server to get public HiPS  per information from [http://aladin.u-strasbg.fr/hips/list|https://github.com/Caltech-IPAC/firefly/pull/url]  the available HiPS images can be retrieved by sending the query like  [http://alasky.unistra.fr/MocServer/query?hips_service_url=*&dataproduct_type=!catalog&dataproduct_type=!cube&get=record|https://github.com/Caltech-IPAC/firefly/pull/url]   * show the list of the found public HiPS in a table"
Answer: 81011.0

User story: "We need to be able to switch between HiPS and FITS depending on the level."
Answer: 181148.0

User story: "The info button show the FITS head for FITS,  it should show the properties for HiPS when HiPS image is displayed."
Answer: 31669.0

User story: "Do the following optimizations:    * The user sometimes does not know what is happening when he click on the zoom.  Give better feedback by displaying the last tile level rendered immediately.  * Give feedback when switch between HiPS repositories  * prefetch the all sky image up front.  * Add sanity check to see if allay image even exist.  * improve all sky drawing performance. "
Answer: 31653.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "In the long run, it should be possible for {{ap_pipe}} (or any other pipeline) to automatically determine the correct templates for image differencing of a particular field. However, this capability has not yet been written.    As a workaround, {{ap_verify}} should add a command-line argument that lets the user specify the template to use with a particular visit. For consistency with {{ImageDifferenceTask}}, the argument should be named {{--templateId}} and take a (list of?) dataId that contain only a visit ID."
Answer: 989466.0

User story: "A {{CompositeFunctor}} currently evaluates itself as follows:  {code:python}      def __call__(self, catalog, dask=False, **kwargs):                  df = pd.DataFrame({k : f(catalog, dask=dask, **kwargs)                               for k,f in self.funcDict.items()})          return df  {code}  This does not take advantage of any parallel computing opportunities, and this is often the speed bottleneck in setting up a {{QADataset}} for interactive analysis.  This computation should be parallelized, either using dask or a straight-up multiprocessing pool"
Answer: 29959.0

User story: "flake8 found the error described in the summary. It appears to be legit and I'm not sure what was intended."
Answer: 576.0

User story: "Reprocess the HSC RC dataset, as defined in [DMTR-31 Sect. 4.1 |https://docushare.lsst.org/docushare/dsweb/Get/DMTR-31], using Stack w_2017_46.  Steps include {{makeSkyMap.py}}, {{singleFrameDriver.py}}, {{mosaic.py}}, {{coaddDriver.py}}, and {{multiBandDriver.py}} (DM-10129/DM-11020)."
Answer: 27391.0

User story: "When creating fake object catalogs using makeSourceList.py or makeSourListGrid.py, it is currently necessary to specify a filter in the dataId. As this task only uses a skyMap, this should not be necessary. Change the behavior of these scripts so that specifying a filter in the dataId is not a requirement."
Answer: 10256.0

User story: "QA drill-down using the interactive QA tools requires viewing image data; ideally attached to some callback, such as clicking on a point in a scatter plot or sky plot.  Do some preliminary investigation of how this might work."
Answer: 30183.0

User story: "The matching calculations done to enable DM-12541 on the scale of a few tracts take a long time.  It would be desirable to be able to persist this match data in order to quickly re-load an already matched {{MultiMatchCatalog}}.  "
Answer: 30187.0

User story: "Computing metrics involving reproducibility requires a framework to match many visit catalogs all to a coadd catalog.  Enable this, and test it by investigating photometric reproducibility in some PDR1 data."
Answer: 104112.0

User story: From the recent HSC data we know that the performance of the PSF modeling code, PSFEx, is poor when the seeing is < ~0.45".  <USER>found that the single pixel basis functions of the PSF model were being Lanczos interpolated.  He updated the code to use the overlap of model basis with the original pixels.  This ticket implements his change.
Answer: 13869.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: AssociationTask currently passes a circle on the sky to load DIAObject/Source from the database wrapper rather than the precise CCD BoundingBox. This means that the metric "Fraction of known previously-known DiaObjects that have detections in a new difference image." in DM-11155 will difficult to interpret as the DIAObjects loaded represent a larger area than the CCD of the current exposure.    This ticket will implement this cut to the CCD BoundingBox by parroting the _trimToBBox method of LoadReferenceObjectsTask.
Answer: 14197.0

User story: "Following the hscPipe 6.0-beta0 release, we need to merge:  * DM-12517: Evaluate (and optionally implement) using SourceDetectionTask in CompareWarpAssemble  * DM-12514: Improve filtering of artifacts in CompareWarpAssemble  * DM-12445: Set appropriate default configs for CompareWarp Coadds  * DM-12539: Fix PSFEx in good seeing  * DM-9147: Implement global sky subtraction  * DM-12540: Add HSM moments that use a circular weight function"
Answer: 19689.0

User story: "Update LDM-534 to provide a test specification which will be executed to satisfy the milestone LDM-503-2 (HSC Reprocessing).    I will provide structure and editing, together with some content; [~<USER> is expected to provide material on QC tests to be performed by the DRP group, while [~<USER> and [~<USER> will provide details on the installation of the DM system at the Data Facility and the execution of the reprocessing itself."
Answer: 94768.0

User story: "Currently {{ap_pipe}} processes one CCD visit at a time.  For  DM-12534 we need to run over the full MVS HITS repository.  This may involve writing a temporary loop or wrapper until we complete DM-11372, which would allow {{ap_pipe}} to process multiple visits at once."
Answer: 40019.0

User story: "Write up the results of the test documented in LDM-533."
Answer: 99081.0

User story: "This ticket is to create a test plan in LDM-533 for the LDM-503-3 milestone occurring this cycle."
Answer: 60263.0

User story: "Implements RFC-409.    If this is as easy as I'm guessing, I should be able to get this done before the RFC is adopted, and then merge it at the same time as DM-12450 to allow me to group the announcements about these changes in behavior."
Answer: 7508.0

User story: This may speed up install times, reduce console clutter, and remove metadata "noise" in constructed docker images.
Answer: 2536.0

User story: "Create a visit tag for all HSC RC data using DESDM. This includes visit/ccd that would fail processCcd."
Answer: 8555.0

User story: "Per discussion on {{#dm-square}}, there are still some C++ tests that are not being driven by {{pytest}}.  Failures in these tests will not be recorded by {{pytest}} in a {{junit}} xml file.  A stop gap solution until all tests are executed under pytest is to artifact the {{*.failed}} files."
Answer: 294.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: "External to the main DESDM FW codes, the prototype and previous tests for this epic have been using codes not in git.    These codes include pipeline-agnostic plugins that allow the DESDM framework to run LSST CmdlineTasks as well as pipeline-specific codes like a specialized query code used when running the DRP pipeline in the DESDM FW."
Answer: 34838.0

User story: "This ticket documents data preparation and loading for the following WISE catalogs:  || Catalog name || PDAC database || PDAC table || IRSA download page ||  | NEOWISE-R Year 1 Single Exposure (L1b) Source Table |  neowiser_year1_00 | neowiser_yr1_p1bs_psd | http://irsa.ipac.caltech.edu/data/download/neowiser_year1/ |    Documentation for loading the catalogs:  * [https://confluence.lsstcorp.org/display/DM/Loading+WISE+catalogs+into+PDAC]"
Answer: 29500.0

User story: "<USER>has calculated some new color terms using the restricted color ranges (DM-12207). These should replace the current ones."
Answer: 1385.0

User story: "{{FitSipDistortionTask}} has no unit tests. Since it is intended as a drop-in replacement for {{FitTanSipWcsTask}} it should be trivial to copy existing tests of {{FitTanSipWcsTask}} and use {{FitSipDistortionTask}} instead.    I tried this with {{test_fitTanSipWcsTask.py}} and found a serious issue:  {code}   Assertion failed: (static_cast<std::size_t>(nGood + nClip) == _data.size()), function rejectOutliers, file src/ScaledPolynomialTransformFitter.cc, line 470.  {code}    Also {{FitTanSipWcsConfig}} has a field numIter and FitSipDistortionConfig does not."
Answer: 9889.0

User story: "Pursuant to RFC-408, we will add h5py to the miniconda distribution shipped with the stack, adding an eups stub package for version control."
Answer: 2944.0

User story: When running naively as command line tasks, the default of makeCoaddTempExp.py and assembleCoadd.py is to [use WcsSelectImages|https://github.com/lsst/pipe_tasks/blob/w.2017.33/python/lsst/pipe/tasks/coaddBase.py#L59] in the "select" subtask. No camera override in obs_subaru/config/(hsc/)makeCoaddTempExp.py or obs_subaru/config/safeClipAssembleCoadd.py so far either.     However, in coaddDriver, the select subtask is [retargeted to PsfWcsSelectImagesTask|https://github.com/lsst/obs_subaru/blob/w.2017.33/config/coaddDriver.py#L14] (select is done before makeCoaddTempExp and assembleCoadd subtasks in coaddDriver).    I'm not sure if it is intentional in the Science Pipelines  (e.g. difference between obs_subaru/config/assembleCoadd.py and obs_subaru/config/safeClipAssembleCoadd.py DM-10634). As the idea of DM-12291 is to follow the pipe_drivers workflow as much as possible, I will override the configs to use     PsfWcsSelectImagesTask in both makeCoaddTempExp.py and assembleCoadd.py in the tests of DM-12291. 
Answer: 2838.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 WarpCompareAssembleCoadd directly creates a detection mask on the warp-difference images from a Chi-Image. This is twice as fast as using SourceDetectionTask. However, SourceDetectionTask is more configurable.  Assuming this extra configurability is worth the speed, switch to SourceDetection.      One way to have both options is to turn the current detection method into a mini PIpeTask to still be able to retarget it. "
Answer: 11659.0

User story: "SQuaSH database backups required alpha features enabled to use CronJob resource (batch/v2alpha1)    This has been deprecated and cluster version 1.8 switchs to batch/v1beta1 which is enabled by default in the API server.     Also we need to fix the {{squash-dash.lsst.codes}} -> {{squash.lsst.codes}} creation which is done manual currently."
Answer: 30382.0

User story: "CompareWarpAssembleCoaddTask is too aggressive.  The edges of difficult-to-subtract bright stars and scattered light in the halo have 1 or 2 epochs deviating from the template. One obvious way to improve is to dilate detections BEFORE filtering instead of after. "
Answer: 4236.0

User story: "Running validate_drp on many full focal plane visits can be quite slow (as is necessary to complete the jointcal/meas_mosiac comparison), with most of the time spent in multiMatch. It appears there are a handful of relatively easy speedups that can be done to it, before we expend the (still necessary) effort to replace it with a fast n-way matcher."
Answer: 2932.0

User story: "Addition and aggregation of metrics and trending type of tell me number of incidents, and etc. Implement initial version as possible. "
Answer: 69067.0

User story: "Research and if possible add initial application level monitoring with API creation."
Answer: 70605.0

User story: "Reiterate with system and project staff regarding incident and response and what should be needed for an incident type, as well as what to monitor and requested changes/additions. Solidify installation of configuration with puppet, etc."
Answer: 69202.0

User story: "6Document the current monitoring for the LSST infrastructure machines in NPCF and in NCSA.   Document the current dashboard for what is currently available, and how a current incident is resolved that was found in monitoring.   "
Answer: 136757.0

User story: "Document Base AA monitoring system, including how-to for adding monitored resources."
Answer: 90821.0

User story: "Create initial monitoring tasks fr Base AA systems-- what is to be monitored, what is an incident, what is the level of response."
Answer: 90735.0

User story: "Configure low-level monitoring applications and initial dashboard-- nagios setup, triggers, etc."
Answer: 90736.0

User story: "Prepare the Base AA system with users, applications, and configuration necessary for running low-level monitoring."
Answer: 70625.0

User story: "Refine initial display elements & architecture. Done in conjunction with monitoring developers."
Answer: 40410.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: "Define initial set of elements for display. Done in conjunction with with steering committee."
Answer: 40411.0

User story: Davix is a library and tools developed at the IT-SDC-ID section at CERN (https://dmc.web.cern.ch/projects/davix/home) to 'make (HTTP) a competitive alternative for high performance I/O and data analysis applications in a global computing grid.'  We perform initials test transfers with the "davix-put" client against nginx webdav endpoints.
Answer: 17.0

User story: "We setup webdav servers with nginx on lsst-ddb-fts1.ncsa.illinois.edu and lsst-ddb-fts2.ncsa.illinois.edu, and transient test instances on verification compute nodes for testing. These utilize the nginx-dav-ext-module to support PROPFIND OPTIONS (which are not supported by  default with nginx) , and they use Basic authentication with access via username & password,  and also client x509 certificates."
Answer: 1.0

User story: "DM-10443 broke ci_hsc because falling back to a {{PosixRegistry}} enabled things to work, but that option was removed."
Answer: 801.0

User story: "We already assume that a list of spanSets representing the artifacts can fit in memory, so we can assume that the list of artifact CANDIDATES can also fit in memory. Lets loop over the warps once, building the count map and candidates at once  and then filter them afterwards."
Answer: 1182.0

User story: "https://ipywidgets.readthedocs.io/en/stable/user_install.html"
Answer: 15691.0

User story: In running makeCoaddTempExp, sometimes warp files would not be created because {{directWarp has 0 good pixels (0.0%)}} ([one example here|https://confluence.lsstcorp.org/display/~<USER>Collection+of+edge+cases]). If the framework/workflow expects the files, missing the files can be considered as a failure.     One way to get around this is to blacklist those specific visit/CCDs so to ignore those inputs, then this case never happens.  But figuring out all CCDs to blacklist can be very time consuming (unless with help of new tools). In this ticket, solve the problem by making {{deepcoadd_directwarp}} an optional output of {{make_coadd_temp_exp}} (p.s. Part was mistakenly [merged previously|https://github.com/lsst-dm/prod_wcl/commit/0b5d33e9ca6351a5c53aceed1ff3739e9d20b168].  The existing tiny tests do not have such cases.)    This implies splitting the "drp-patch" block into two. The first one has only {{make_coadd_temp_exp}} and allows optional warp outputs.  In the subsequent block a new query is done to use only the available warps from the previous block, rather than everything inferred by the overlap table.  
Answer: 1033.0

User story: "Develop a proposed service level agreement for the Chilean Base Authentication and Authorization system."
Answer: 524172.0

User story: "Interface with NCSA technology group to review and compare existing organizational and desired project processes ."
Answer: 66087.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: "Contact relevant project personnel (e.g., T/CAMs, subsystem reps) and place announcements in project forums to advertise new procedures."
Answer: 433216.0

User story: "Revise identified documentation with new procedure(s)."
Answer: 433228.0

User story: "Identify existing project documents that need to be revised to reflect new procedures. e.g., developer documentation on confluence and developer.lsst.io."
Answer: 5.0

User story: "Create & vet incident response process"
Answer: 7.0

User story: "Following review comments on DM-12429, the policy for obs_comCam is not the minimal required to produce the same functionality, as a lot of things are redefined identically to how they are defined for the default in obs_base. This ticket is to make a best-effort at improving that situation, _and_ to fix a number of places in the path templates that are not currently correct (this is a newish obs_package and they were born wrong)."
Answer: 21735.0

User story: As part of converting the {{tag-git-repos}} job to jenkins pipeline, a new convience method named {{notify.wrap()}} was introduced that can replace this chunk of boilerplate that is current present in most (all?) of our pipeline scripts:    {code:java}  try {    notify.started()    // do stuff  } catch (e) {    // If there was an exception thrown, the build failed    currentBuild.result = "FAILED"    throw e  } finally {    echo "result: ${currentBuild.result}"    switch(currentBuild.result) {      case null:      case 'SUCCESS':        notify.success()        break      case 'ABORTED':        notify.aborted()        break      case 'FAILURE':        notify.failure()        break      default:        notify.failure()    }  }  {code}    Which may be converted to:    {code:java}  notify.wrap {    // do stuff  }  {code}  
Answer: 40456.0

User story: "The current bandpass implementation leads to an inaccurate effective wavelength calculation for DCR. That implementation should change, and the way the bandpass is used throughout the prototype code should be updated"
Answer: 34721.0

User story: "In order to simplify the transition of the prototype DCR code to the stack, several components should be re-written. This includes the PSF model, which currently depends on a lot of old and complicated code that deconvolves DCR from measured PSFs."
Answer: 1266.0

User story: "Break different sections into subconfigs."
Answer: 1413.0

User story: "[~<USER> has done a bunch of math for calculating things related to refraction. Some of these should live in VisitInfo, since it knows the necessary values for the calculations. In particular, {{visitInfo::getParallacticAngle()}} would be very helpful. I suspect that there are some others in his DCR code that we'd like to have more broadly available.    Ian suggests that he could do this as a pair coding exercise with [~<USER> or [~<USER>, since he doesn't know C++ that well."
Answer: 70753.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: "I recently created DMTN-064 to describe HSC donut fitting.  This issue is to migrate the existing donut fitting documentation at https://paper.dropbox.com/doc/Hyper-Suprime-Cam-Donut-Analysis-8zNlUbtorKfyfuVtIySXz to the DMTN, as well as to polish it up for publication."
Answer: 182803.0

User story: "The existing donut analysis plotting tools were created before our understanding that both intra and extra focal fits would be required to predict an in-focus PSF.  Several of these tools therefore incorrectly attempt to make plots of the optics PSF given only an intra or extra focal fit.  These should be reworked to make accurate optical PSF plots."
Answer: 155441.0

User story: "Make bokeh part of default set of packages."
Answer: 157.0

User story: "While working on the design of how the DCR algorithm will fit in the stack, the existing prototype code is expected to change to reflect new functionality and limitations. "
Answer: 89518.0

User story: "The DCR technote DMTN-037 needs to be rewritten for publication in a journal. This bucket ticket represents the amount of effort that will be spent on that revision in the current sprint."
Answer: 50587.0

User story: "Revise the DCR technote DMTN-037 based on feedback received on the initial full draft."
Answer: 41997.0

User story: "Review the design of the DCR algorithm in the stack, and gather feedback from stakeholders."
Answer: 334341.0

User story: "Now that the prototype DCR code is finished it needs to be refactored and brought in to the stack. Since there is a substantial amount of code involved I will write an initial design first. The result of this ticket will be a brief report describing the code that will be added to existing packages and any anticipated changes."
Answer: 262031.0

User story: "The large-scale modes in the FGCM illumination correction are caused by the differing pixel area across HSC that is not corrected for in the ISR processing.  Adding this to the stars before applying FGCM will help the fitter and is straightforward."
Answer: 23218.0

User story: "Testing on scaled up consumers.  Results to be reported in a revision of DMTN-28."
Answer: 120716.0

User story: Represent Alert Production in the Lossy Compression Working Group. This is mainly expected to involve communicating with other AP stakeholders regarding plans, requirements, and necessary tests to show that a compressed dataset is "good enough".
Answer: 43375.0

User story: "The stack release v14.0 just came out. It would be useful if v14.0 is available in the shared stack on lsst-dev. "
Answer: 69459.0