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: "The default implementation of SuperTask.runQuantum currently passes additional _output_ data ID information to run, as this is necessary in at least some contexts in which {{run}} needs to be able to group input datasets.  However, the way this is passed is confusing (the kwargs generated do not have names that suggest that they are IDs), and the need for these IDs may be sufficiently rare that most SuperTasks should not be required to accept them.    One possibility for how to address this would be:   * runQuantum always passes just a single data ID (the quantum data ID, not the data of either inputs or outputs) to run, as an always-optional {{dataId}} keyword argument (i.e. SuperTasks must permit this argument to be None).  That will at least meet the needs of SuperTasks that want to use the data ID for diagnostic or custom-provenance purposes (see also DM-14821).   * SuperTasks that need to do data ID grouping in {{run}} should override {{runQuantum}} themselves.   * To make the above easier / less verbose, we should look for ways to make some of the logic in the default implementation of {{runQuantum}} available to subclasses that override that method (e.g. via utility methods that do some of the work).    I'm open to other ideas as well, and I should note that I have not thought much about how this proposal would change which of our concrete SuperTasks would need to override {{runQuantum.}}"
Answer: 66422.0

User story: "We've accidentally made it a bit painful to use the DatasetRef and Butler classes together, because Butler's {{get}} and {{put}} interfaces require one to unpack the contents of a DatasetRef.    Make sure {{Butler.get(datasetRef)}} and {{Butler.put(obj, datasetRef)}} work.    Note that the former is not just a renaming of {{Butler.getDirect}}; it should not permit loading datasets outside the {{Butler}}'s collection, and it should not require the {{DatasetRef}} to have already been associated with a dataset_id (though it should take advantage of one, if present).     "
Answer: 64490.0

User story: "We frequently need to encode at least (camera, visit, sensor), (skymap, tract, patch), and (skymap, tract, patch, abstract_filter) data IDS into unique _reversible_ integer IDs.  Gen3 needs to provide methods for translating both from dict to int and from int to dict.  Because we'd like to be able to further pack these with Source IDs, we also need to be able to report how many bits are utilized by the data IDs.  This is tricky because the number of bits occupied by any particular data ID key-value pair depends on the particular Camera or SkyMap with which it is associated.    Ideally, at least the dict->int conversion would be handled via a custom, dict-like DataId class that makes the packed integer ID available as a property or method; we'd like to have something we can pass to {{Task.run}} methods that shouldn't require a butler but may want to able to report data ID information in either form for diagnostic purposes."
Answer: 298226.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: "PropagateVisitFlagsTask is a non-CmdLineTask that uses the Butler, and hence can't be directly used as a subtask of SuperTasks.  We need to separate interfaces that use the Butler and do I/O from everything else."
Answer: 691470.0

User story: "Some of the work currently done by LoadReferenceTask - the actual lookup of which shards overlap an area of interest - will be done by preflight (outside Task code) in the Gen3 era.  That will ultimately let us greatly simplify it, but in the meantime we will need to make sure it provides APIs appropriate for both CmdLineTask usage and SuperTask usage.    Reference catalogs also have a lot in common with catalogs of simulated objects we might want to insert into real images - they'll have different columns, but we'd want to shard them and look them up the same way.  We should look for opportunities in this refactor to support that use case as well.     "
Answer: 309327.0

User story: "On master, ci_hsc simply runs all CmdLineTasks in the prototype DRP pipeline, then runs custom validate code after each to check that outputs exist.    On the gen3-middleware branch, we also create a Gen3 data repository containing all outputs and re-run all validation code.    Once SuperTask conversion begins, we will want to have an easy way to include executing those SuperTasks in ci_hsc, regardless of whether preceding CmdLineTasks have been converted (we can do this by allowing SuperTasks to use the converted Gen2 outputs as inputs).  We'd then want to follow this up with validating those outputs as well.    In the long-term, we will those validation steps to themselves be SuperTasks, and we'll want them to live outside ci_hsc.  We'll also want to replace ci_hsc's SCons control logic with a real SuperTask executor.  With those goals *in mind*, the end point of this ticket should just be a way to easily add a concrete SuperTask to ci_hsc and validate its outputs.     "
Answer: 666730.0

User story: "In order to proceed in earnest with CmdLineTask->SuperTask conversion, we need a way to be able to run at least a single Quantum easily with the command-line, even if this requires all inputs explicitly provided by the caller.  We expect this functionality to be removed once a complete command-line executor is available, and it's possible that (some part of) that functionality is close enough that we could skip this step entirely."
Answer: 174042.0

User story: This ticket is a zero-SP ticket intended to help organize PipelineTasks conversion work.   * Tickets that involve actually converting one or more CmdLineTasks to PipelineTasks should have a "is contained by" relationship with this issue.   * Tickets that require work that must be done before we can start converting CmdLineTasks to SuperTasks should have a "blocks" relationship with this issue.    Blocker tickets may include changes to both the Gen2 CmdLineTasks or their dependencies or the Gen3 Butler or PipelineTask framework.
Answer: 707305.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 Developer Guide, documentation for LICENSE and COPYRIGHT were originally documented in https://developer.lsst.io/stack/package-docs.html. That page will be rewritten to document the new documentation system for packages and pipelines.lsst.io.    This ticket is to move the LICENSE and COPYRIGHT discussion out of that page before it is rewritten, and to also add additional context around copyright management in DM."
Answer: 10094.0

User story: "Current alert_stream alert deserializer/printer will print all received alerts to stdout, which will overwhelm the logs.  Change this to every Nth alert as a command line argument."
Answer: 16324.0

User story: "Currently {{daf.butler.core.views.makeView}} uses {{.execute_at('after-create', metadata)}} (and {{'before-drop'}}) to trigger view creation (e.g. execute {{CREATE VIEW}} statements).  Unfortunately this is deprecated and spits out warnings.  Update to use: DLLEvents (http://docs.sqlalchemy.org/en/latest/core/events.html#sqlalchemy.events.DDLEvents) instead."
Answer: 1318.0

User story: Test the speed and accuracy of convolution (analytic and empirical image-based) of single and double Sersic models with single-components PSFs (single Moffat, 1-2 Gaussian/shapelet). Then create noisy realizations of the galaxy (and PSF?) and fit with both the correct PSF/galaxy model and incorrect ones, measuring the bias in total flux and/or shape. See if there's a way to quantify how "wrong" the parameters are - this should be easy when using the right galaxy model/wrong PSF, but not so clear if using the wrong galaxy model.    Single model test: [https://github.com/lsst-dm/pyprofit/blob/master/tests/fitsinglemodel.py]    Multi-model tests: [https://github.com/lsst-dm/pyprofit/blob/master/tests/fitmodels.py]    For now, multi-model tests include single-Gaussian, single-Moffat and double-Gaussian PSFs, and a variety of plausible single-Sersic galaxies (I will add expDev and/or double-Sersic shortly).    Notebook to analyze/plot results: DM-15051
Answer: 151277.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: [~<USER> [writes|https://lsstc.slack.com/archives/C2JPXB4HG/p1529023082000159]:  {quote}  {{skyMap}} behaves wrongly around ra = 360^\circ. For example, the following assertion does not hold:  {code}  skyMap = pickle.load(open("skyMap.pickle", "rb"))  assert(9712 == skyMap.findTract(skyMap[9712].getCtrCoord()).getId())  {code}  This bug is causing {{detect_isPrimary = false}} for all objects around ra = 360^\circ .  I have no idea what's the very cause of this bug, but at least the following lines are wrong:  https://github.com/lsst/skymap/blob/master/python/lsst/skymap/ringsSkyMap.py#L135  When {{ra - self.config.raStart}} is near 2pi, tractNum will be 1 plus its maximum permitted value, which results in the returned tract located in the northern ring.  EDIT: This is incorrect. The truth is tractNum starts with 1. And it's not " {{ra - self.config.raStart}} is near 2pi" but " {{ra - self.config.raStart}} is near 0" that is problematic. --End EDIT  It should also be warned that {{math.fmod()}} in python behaves just as {{fmod()}} in C. It returns negative value when {{ra - self.config.raStart < 0}} . In that case {{int(... + 0.5)}} should be {{int(... - 0.5)}} (But I suggest using a homemade fmod that would always return positive value) (edited)  The {{fmod()}} misuse is irrelevant to the current problem because {{self.config.raStart = 0}} for now.  {{RingsSkyMap.getRingIndices()}} also behaves wrongly around the south pole.  Let the return value {{(ringNum, tractNum)}}.  {{tractNum}} usually starts with 1.  But from {{getRingIndices(index=1)}} is returned {{tractNum = 0}} .  As a result, the 0-th ring has 11 tracts while {{self._ringNum[0]=10}} ,  and skyMap[1] and skyMap[11] are exactly the same.  {quote}    We need to fix these problems without renumbering all the tracts because there is existing data that we don't want to invalidate.
Answer: 13071.0

User story: "The 16.0 pipeline.lsst.io branch still need to be updated to refer to the 16.0 release instead of the 15.0. Files to be updated are newinstall.rst, docker.rst and demo.rst"
Answer: 72270.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 "demo" currently exists as a special snowflake feature of jenkins jobs and is not packaged as an an eups product. A script is currently invoked by the CI machinery after an {{lsstsw/lsst_build}} or {{eups distrib install}} has completed which downloads the demo repo from github as a tarball.    An unfortunate consequence of this implementation is that changes on the master branch of the demo result in previous git tags no longer working with the demo when built by {{ci-scripts/lsstsw}} and requires knowledge of the correct git ref to use after a direct {{eups distrib install}}. This also presents an irritation when tagging an official release as there is no source of truth as to where the tag should be located, requiring human intervention. For at least the third time, the demo on master has changed during the release process and now fails with the current release candidate.    A much less error prone solution would be to convert the demo into a regular eups product, which is a dependency of either {{lsst_distrib}} and/or {{lsst_ci}}. This would result in demo metadata being incorporated into eups distrib tags and solving the science-pipeline/demo version mismatch problem both for end users with a local installation and under CI.    I believe the basic tasks to accomplish this would be:   - convert {{lsst/lsst_dm_stack_demo}} into an eups product – essentially add a {{ups}} dir and a table while which depends on {{lsst_apps}}   - add {{lsst_dm_stack_demo}} as a dependency of {{lsst_ci}} and/or {{lsst_distrib}}   - add a test script under {{lsst_ci/tests/}} to trigger a demo run   - remove {{lsst-sqre/ci-scripts/runManifestDemo.sh}} and update {{lsst-sqre/ci-scripts/lsstswBuild.sh}} to not run the demo   - update various jenkins jobs in {{lsst-sqre/jenkins-dm-jobs}} to {{setup lsst_dm_stack_demo}} rather then invoking {{runManifestDemosh.sh}}
Answer: 79123.0

User story: The package-docs CLI requires a {{--dir}} argument to define the root {{doc/}} directory. The default is the current working directory. It would be nice if the command could "discover" that {{doc/}} directory if the current working directory is anywhere inside a package. This would greatly improve the usability of the package-docs CLI.    Something similar can also be done for the stack-docs CLI, though in that case the goal is to find the conf.py file at the root of the {{pipelines_lsst_io}} repository.
Answer: 19961.0

User story: "When reading in the attached file via _lsst.verify.SelectionSet.load_single_package_, it returns an empty set. This means there is something wrong with the file, but the load fails silently. It should yell at me as to the issue with what I'm passing it."
Answer: 50363.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: "See     [http://adsabs.harvard.edu/abs/2004PASP..116..133L]    for details and motivation.    (According to [~<USER>, this is already on the radar at some level, but I didn't see a ticket, so I created one).         Paper:    [https://arxiv.org/pdf/astro-ph/0312483.pdf]    Implementation in afw_display and astropy:    [https://github.com/lsst/afw/blob/master/python/lsst/afw/display/rgb/rgbContinued.py]    [https://github.com/astropy/astropy/blob/master/astropy/visualization/lupton_rgb.py]     "
Answer: 138325.0

User story: "Firefly currently complains if stretch min/max are set to values that are outside the actual range of pixel values, but this is useful when trying to put different frames on the same color scale (for instance, one may want to compare a model with no negative pixel values with data that does have negative pixel values due to noise, without truncating the noise).    I think this is most important for Data bounds, but it may make sense some other kinds of bounds as well."
Answer: 381775.0

User story: "Update product tree csv in LDM-294"
Answer: 17660.0

User story: In trying to define a test script for [LVV-T16|https://jira.lsstcorp.org/secure/Tests.jspa#/testCase/LVV-T68], I was reminded that we may not be able to "just run" an externally-developed photometric redshift code during DRP; many modern photometric redshift codes require some kind of training step, which typically requires as input both photometry from the survey for which redshifts are being estimated and a sample of spectroscopic or otherwise more secure redshift estimates for a subset of the catalog.  Furthermore, there are frequently multiple cycles of training, estimation, and validation before the release of any particular photometric redshift catalog.    The work of collecting, curating, and standardizing spectroscopic training data is (to my understanding) beyond the scope of DM, but DM outputs are also needed inputs to this training step.  At some level, I believe that train/estimate/validate iteration is also outside DM scope; all I think we've signed up for is a final "estimation" step, which cannot be done in isolation.    The only way I see to resolve this without increasing DM scope or delaying the release of photometric redshifts until well after each main DR would be to define a procedure that involves the external scientists responsible for photometric redshift estimation directly in the data release process itself.    Note: I don't recall any mention of this in [DMTN-049|https://dmtn-049.lsst.io/], but I should read again to check.
Answer: 29330.0

User story: DMS-REQ-0326 says that we need "parameterized approximate" representations for image depth and masks.  What we actually care about is that the representations be compressed and efficient for use at several different scales, which implies that they must be approximate.
Answer: 661012.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 this technote we evaluate the existing DM tools, and the the need of new tools for:  {quote} * Collecting the data quality metrics from the _Single Frame Processing_ pipeline;   * Storing the data quality metrics in the Prompt QC database;   * Publishing data quality metrics to the OCS;   * Accessing the Prompt QC and EFD databases;   * Implementing the Prompt Data Quality Report;   * Running and publishing the Prompt Data Quality Report.{quote}"
Answer: 109297.0

User story: "Perform and check consistency in the creation of FITS at the FITS File Assembly at NCSA pathfinder integration activity."
Answer: 5614.0

User story: I'm going to have DM-14574 go into review so that the design for the Simple model for the magnitude-based photometry fitter is happy, before I dig into the more complicated Constrained model. So, 14574 becomes "implement the simple model" and this ticket is then to implement the constrained model.
Answer: 99679.0

User story: "Currently, the system looks for a the {{.user_setups}} file in {{$HOME}} and adds a template file there if it doesn't exist.  It should, instead, be looking in {{$HOME/notebooks}} as that is where the file is actually sourced."
Answer: 263.0

User story: "Write a new object-oriented interface for source modelling to replace the existing functional-only pyprofit implementation, both to make writing systematic tests easier (DM-14810) and as a prototype for the as-yet-unnamed CModel replacement.    These objects can be found at [https://github.com/lsst-dm/pyprofit/blob/master/python/objects.py], along with some miscellaneous convenience functions in [https://github.com/lsst-dm/pyprofit/blob/master/python/util.py]."
Answer: 242137.0

User story: "The sphinx_automodapi extension is now available as a standalone package at http://sphinx-automodapi.readthedocs.io/en/latest/ / https://github.com/astropy/sphinx-automodapi    Formerly it was part of astropy-helpers. Switching to this standalone version is good for us since it will reduce the overall weight of documenteer's dependencies.    This is targeted for the 0.3 release of documenteer."
Answer: 21686.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: As we have more projects using Firefly at different stages of its development, it is necessary for project to know which version of Firefly it is using.  Git commit ID uniquely identifies the point of the build.    * provide an API call to get the commit ID string   * display the commit ID as part of the build information   ** dev currently: "v1.0.0_Development-0 Built On:Sat Jun 09 18:05:11 PDT 2018"   ** IRSA ops: v3.0.0_Final-2629 Built On:Tue May 15 16:07:17 PDT 2018    We may want more discussion on how/where to display this in operations.     Implemented as the following:    Show a detail view of the version info when the shorten version is clicked.   * click on the version info on the lower-right corner to see the details    Exposes the same information via the JS API as well as from Java server-side environment.   * In JS, open a demo page, open console. In console, enter {{> window.firefly.util.getVersion()}}
Answer: 37422.0

User story: "Create a {{remote-code-block}} Sphinx directive that mirrors how {{literal-include}} works, but permits a URL so that the content is downloaded from an external https URL.    Caching should be included so that docs can be built offline. The intersphinx extension might be a good guide for how to implement caching.    This directive is needed to feature content from https://github.com/lsst/templates in documentation projects like the Developer Guide."
Answer: 1411.0

User story: "Package the whole setup script in Docker"
Answer: 17123.0

User story: "We are using plotly-1.28.2.min.js As of today, the latest release is plotly-1.38.3.min.js.    A lot of bugs in scattergl have been fixed, we might want to use scattergl for larger scatters.    One of the bugs still present in scattergl is disappearing error bars on relayout. For this reason, we might not want to use scattergl as a default plot when the number of points is reasonably low."
Answer: 22960.0

User story: "Currently {{module-toctree}} and {{package-toctree}} directives introduced in DM-14053 are not sorting their lists. This ticket will implement sorting for those directives."
Answer: 1075.0

User story: Allow "." and "_" in LTD edition names since those are used for Git and EUPS tags by the LSST Stack (LSST Science Pipelines). This is needed to properly version and deploy pipelines.lsst.io from the LSST Science PIpelines' code base.
Answer: 33105.0

User story: "Add support for views to schema object. Preferably through https://pypi.org/project/sqlalchemy-views."
Answer: 8537.0

User story: "Mount /scratch to Firefly and point workdir to that shared dir."
Answer: 14727.0

User story: "Following DM-14259, we can run the AP pipeline on the verification cluster and following DM-15080 we have new templates. Use them to process HiTS 2015, difference it with those templates, and record the results.    Aim to come up with the fastest/least manual possible procedure for this, so that we can easily perform regular reprocessing using the same commands."
Answer: 214622.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 have decided that the all datastores must provide a simple table indicating which datasets they have, but that information relating to internal details such as filenames, checksums, file sizes etc should be in an "internal" table under the control of each datastore.
Answer: 106254.0

User story: "Add support for XY0 using LTV1/2 or CRVAL\{1/2}A.    XY0 will be default for slate.html entry point. Therefore it will be the default for the API."
Answer: 275.0

User story: the following region text sample has no text display:     text 2101 2131 "my label"
Answer: 195.0

User story: "Prepare a brown bag presentation on the state of the mini-broker.    Describe current capabailities and (briefly) how to use them (a reference to the technote is fine; we don't need to walk through it in detail). Raise the outstanding questions, primarily:    - How to limit resources  - How to add/remove filters dynamically  - How to ensure security for the host    See if the audience has suggestions/requests/useful discussion."
Answer: 40457.0

User story: "What Python capabilities can we use to limit the resource usage of filters in the current (per DM-13476) mini-broker system?    Can you use calls to {{setrlimit}} (or similar) to limit the resources used by processes you're filtering? How about limiting things like network connections? Filesystem access?    Produce a brief report on what's possible and what isn't."
Answer: 40466.0

User story: "Look at restricted Python environments like that produced by ZTF for alert filtering, or https://github.com/zopefoundation/RestrictedPython, or any others you can find by Googling.    Do they help management of filters in the mini broker? In particular, do they contribute to:    - Security of the host system (limiting access to the filesystem, spawning other processes, network connections, ...)  - Limiting total CPU usage or runtime;  - Limiting memory usage.    Produce a report (perhaps a technote, but something briefer would be fine if there's not much material) describing the systems you've looked at, a note of their capabilities, and an evaluation or not they could be useful for the mini-broker system"
Answer: 46014.0

User story: "Update with the proper entries the 16.0 pipelines.lsst.io branch in order to be completed with the proper information."
Answer: 4535.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: "When attempting to combined HSC PDR1 (DM-13666) data for WIDE and DEEP, the following Butler construction does not work correctly:  {code: python}  butler = dafPersistence.Butler(inputs=[{'root': '/datasets/hsc/repo/rerun/DM-13666/WIDE/'}, {'root': '/datasets/hsc/repo/rerun/DM-13666/DEEP/'}])  {code}  One clue is that this prints the following INFO:  {code: python}  CameraMapper INFO: Loading exposure registry from /datasets/hsc/repo/registry.sqlite3  CameraMapper INFO: Loading calib registry from /datasets/hsc/repo/CALIB/calibRegistry.sqlite3  CameraMapper INFO: Loading Posix exposure registry from /datasets/hsc/repo/rerun/DM-13666/DEEP  CameraMapper INFO: Loading calib registry from /datasets/hsc/repo/CALIB/calibRegistry.sqlite3  CameraMapper INFO: Loading exposure registry from /datasets/hsc/repo/registry.sqlite3  CameraMapper INFO: Loading calib registry from /datasets/hsc/repo/CALIB/calibRegistry.sqlite3  CameraMapper INFO: Loading calib registry from /datasets/hsc/repo/CALIB/calibRegistry.sqlite3  {code}  And there should not be anything with Posix registries here.  (note that if you reverse the order of the inputs, then the WIDE gets loaded as a Posix registry)    Upon deeper inspection, the problem is logged to debug in getParentRegsitry (sic): https://github.com/lsst/daf_persistence/blob/1e7c341a1a884cf06fc74a946a126c1f72f56360/python/lsst/daf/persistence/butler.py#L570 (and following).  I believe that on the first call to {{_setParentRegistry()}} this argument is `None` (not sure why), but on subsequent calls (after {{repoData.repo = Repository(repoData)}} is called) then it's okay.    I checked what would happen if instead of kicking out instead it calls {{parentRepoData.repo = Repository(parentRepoData)}} and that appears to work, though I'm afraid of the side-effects.  (Although it does pass all local scons tests)."
Answer: 26579.0

User story: "Thereby implementing RFC-489."
Answer: 4.0

User story: "SNFactory has been collecting spectra of standards stars since 2006.    We compared the atmospheric parameters that they extracted with the ones interpolated from NASA MERRA-2 tables.          "
Answer: 10002.0

User story: "Update READMEs and cleanup examples"
Answer: 2620.0

User story: "Make sure the blocking timeout for webserv is close to 2 hours."
Answer: 1975.0

User story: "ipympl may restore interactive matplotlib widget functionality.  See how close it comes."
Answer: 311.0

User story: "Until we go to Java 10 we need a way to control the number of  cores the firefly docker container uses.         The docker container will name allow for a environment variable JVM_CORES"
Answer: 102.0

User story: "Attempt to reproduce results DMTN-037 based on the stackified DCR code (DM-9613). If there are any changes, account for them and fix regressions or update the technote to reflect improvements.    (Spend no more than a couple of days on this; if you find major discrepancies which need more work, file tickets to investigate them.)"
Answer: 237862.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: "Based on the stackified DCR code provided on DM-9613, update {{ImageDifferenceTask}} to build and use DCR-corrected templates."
Answer: 86733.0

User story: "Minor tweaks to the SuperTask base class interface, prior to starting the work of adapting concrete CmdLineTasks to that interface.  Includes:     - Making sure coding conventions are used consistently.     - Making sure config/schema writing is handled appropriately.     - Adding introspection and other interface for input/output datasets used/created in Task initialization (will be used only for schemas).     "
Answer: 6064.0

User story: This is a proof of concept based on [this post | https://bokeh.github.io/blog/2017/7/5/idiomatic_bokeh/] to create new charts in Bokeh using the Models API.    This method of development is called "additive development", you start with an empty canvas and  explicitly add the Bokeh Glyphs to compose the new chart opposed to removing or changing the plot defaults when using the Bokeh plotting API.
Answer: 21253.0

User story: "Macro to extract product tree from Magic Draw"
Answer: 28872.0

User story: "Take the requirements spreadsheet from [~<USER>, add it into the MagicDraw model in LDM-638, make the document, and submit to CCB for review."
Answer: 25659.0

User story: "Prepare 16.0 science pipeline release.         Community page status available at:    https://community.lsst.org/t/science-pipeline-release-16-0-status-and-discussion/2944"
Answer: 69374.0

User story: "Prepare and give a brown bag-style overview of how l1dbproto and AssociationTask work."
Answer: 412125.0

User story: "Implement forced photometry on PVIs in the context of alert generation. "
Answer: 148544.0

User story: "Update the  [tutorial-lsst2017|https://github.com/lsst-dm/tutorial-lsst2017] tutorial notebook to make it work with a recent stack. "
Answer: 15971.0

User story: "In order to implement forced photometry in AP pipe, we're going to need to understand how the forced photometry tasks in meas_base works. Take a look at {{ForcedPhotCcdTask}} (and the rest of its class hierarchy) and figure out how it all fits together."
Answer: 18988.0

User story: "Please sort out travis and deployment for recent tech notes: DMTN-080 (which was created manually), 81, 82, and 83, 84. The latter 4 were created by sqrbot but deployment credentials were not created (I did turn on travis manually)."
Answer: 8571.0

User story: "when we are loading results tables from workers we use {{LOAD DATA INFILE}} to efficiently import data (from protobufs), but we must escape the values ourselves. We currently do that in ProtoRowBuffer.h, according to the rules in [the mysql LOAD DATA INFILE documentation|https://dev.mysql.com/doc/refman/8.0/en/load-data.html]. However, our binary data (in a {{blobField}}) can contain backslash which is also the escape character, and this needs to be escaped (but is not indicated in the mysql documentation and so was not done).     "
Answer: 50192.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Run ap_proto against Oracle instance at NCSA and extract some performance numbers from these tests."
Answer: 94923.0

User story: "update DMTN-025 with:  - parsl  - desdm framework  - current status"
Answer: 28508.0

User story: "Upgrade Kafka to Confluent 4.1.1/ Kafka 1.1.0 for alert stream distribution system to take advantage of any bug fixes.  Current version is Confluent 3.2.0/ Kafka 0.10.1."
Answer: 3180.0

User story: "NumPy is changing the default behavior of {{numpy.linalg.lstsq}}'s {{rcond}} parameter, and now warns on any call that uses the default.  meas_deblender does that extensively, resulting in lots of warnings."
Answer: 1488.0

User story: "The  {{d_2018_06_06}}}} nightly is still running but has already failed 3 times to build the {{centos-7.devtoolset-6.miniconda3-4.3.21-10a4fa6}} tarballs.    https://ci.lsst.codes/blue/organizations/jenkins/release%2Fnightly-release/detail/nightly-release/316/pipeline/160"
Answer: 49332.0

User story: "Finish draft, get reviewed and publish DMTN-080 the technote describing CompareWarp"
Answer: 125258.0

User story: "When using the Firefly backend for {{lsst.afw.display}}, the first {{MaskedImage}} or {{Exposure}} displayed via {{Display.mtv}} has a wonderful mask overlay (much better than DS9's!).    Unfortunately, if I call {{mtv}} a second time on the same {{Display}} instance, the mask overlays do not appear, even though the image itself is updated.    If I close the image window in Firefly itself before calling {{Display.mtv}}, things work as expected.    If a quick fix is possible, it'd be great to get it in this week so I can avoid demoing the workaround at LSST@Europe3 next week (but it's not a terrible workaround if quick fix is not possible)."
Answer: 4222.0

User story: When using {{lsst.afw.display.dot}} with the Firefly backend, positions appear at a half-pixel offset from where they should; LSST convention is to label the *center* of the lower-left pixel (0, 0).    I also see the same half-pixel offset in the mouse pixel coordinates displayed in the upper right corner of the Firefly GUI, so I'm guessing this is just because Firefly (presumably) using a coordinate convention in which integers are pixel boundaries rather than pixel centers.  If it's possible to address that, it'd be very nice to also include the "xy0" offset our image objects carry as well (note that {{dot}} already takes care of this offset correctly, presumably by removing it in Python before passing the position to Firefly).    I'd really appreciate a quick fix so I don't have to work around this in the tutorial notebooks for LSST@Europe3 next week.   If the only short-term options is a workaround for {{dot}} in the display_firefly Python code, I can do that much myself; please let me know if I should.
Answer: 4429.0

User story: "Create landing page that's better than the default 404"
Answer: 2636.0

User story: "Make sure that git lfs has been run as the user."
Answer: 2649.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: "Reprocess the HSC RC2 dataset, as defined in DM-11345, using Stack w_2018_26. Steps include {{makeSkyMap.py}}, {{singleFrameDriver.py}}, {{mosaic.py}}, {{skyCorrection.py}}, {{coaddDriver.py}}, and {{multiBandDriver.py}}. "
Answer: 40279.0

User story: "Reprocess the HSC RC2 dataset, as defined in DM-11345, using Stack w_2018_24. Steps include {{makeSkyMap.py}}, {{singleFrameDriver.py}}, {{mosaic.py}}, {{skyCorrection.py}}, {{coaddDriver.py}}, and {{multiBandDriver.py}}. "
Answer: 28517.0

User story: "Allow configuration of a container-startup parameter so that we can pass URLs to be cloned by user notebooks down from the spawner."
Answer: 32948.0

User story: "Run pipe_analysis scripts   # visitAnalysis   # coaddAnalysis   # colorAnalysis   # compareVisitAnalysis   # compareCoaddAnalysis    and validate_drp  # matchedVisitMetrics.py  # validateDrp.py   # reportPerformance.py   # dispatch_verify.py    with the w_2018_22 RC2 outputs from DM-14547"
Answer: 55.0

User story: "DM-14429 moved afw.geom into lsst.geom. Since ap_association is not yet part of lsst_distrib this change did not propogate through the package. This ticket will change app instances of afwGeom to geom."
Answer: 341712.0

User story: "My plan is to add a fake globular cluster to an HSC coadd patch (COSMOS, tract=9813, patch=4,4, from the last PDR1 reprocessing on DM-13666), then demonstrate using Tasks (specifically SourceDetectionTask), some lower-level objects (Psfs, Catalogs, Images), and image display (afw.display with Firefly backend) by trying to do iterative detection and PSF fitting to recover better photometry than what the stack would do naturally.    I'm not sure that will work out well algorithmically, but it's at least a believable use case that should provide a good overview of some important parts of our code."
Answer: 39371.0

User story: "Snif instrument on the UH telescope at Mauna Kea, Hawaii has been routinely observing standard stars since 2006.    From the spectra, atmospheric parameters are being extracted following the method described in Button et al. 2012.         Here is a first visual comparison of the Ozone parameters as reconstructed by the SNFactory team and from an interpolation of the the MASA MERRA 2D table.    !satVSsnf.png!"
Answer: 8826.0

User story: "See https://gitlab.in2p3.fr/fjammes/module-site_qserv/commits/tickets/DM-14679"
Answer: 30584.0

User story: "Enable others to retrain the S/G classifier. It should make COSMOS training set available. Task should:   * Match training data to new reruns that overlap cosmos   * Retrain based on new columns   * Write out classifier and column names and camera info"
Answer: 166671.0

User story: "Update dmtn-060 with broader survey of data management / file transfer systems and tools."
Answer: 2576.0

User story: "Set up LSST Europe cluster"
Answer: 29886.0

User story: "The following changes are required on the SQuaSH interface in order to support the LDF environment:   - Support HSC filter NB0921"
Answer: 60524.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 fgcmcal expects to work with stars that have (e.g.) all of griz observations.  This restriction can be relaxed, with the caveat that chromatic corrections will not be as accurate (or non-existent).  However, the expanded calibrated footprint is often a trade-off that is useful.    There are actually two parts to this: 1) Stars at the edges of the footprints/in chip gaps may be well-calibrated because of information from neighboring stars on the footprint.  The FGCM code supports this already, but some configuration changes and small fixes to make this work properly and efficiently; 2) There may be times that the footprint of the survey has different bands in different regions.  This will require some checks and changes."
Answer: 34705.0

User story: "One of the outputs from fgcmcal is a dense catalog of calibrated reference stars.  This needs to be converted to a format that can be used as a reference catalog in the stack.  At the same time, the stars will have to be put on some sort of absolute photometric scale.  At the moment, this will be on this ticket as well."
Answer: 184638.0

User story: Run fgcmcal on the reprocessing of HSC PDR1: https://confluence.lsstcorp.org/display/DM/S18+HSC+PDR1+reprocessing   This is the first mid-to-large-scale test of the lsst stack version of fgcmcal, and there may be issues which will be addressed in related tickets.  The goal of this processing is to produce a "standard star" catalog that can be used as a dense reference catalog for computing (gray) zeropoints with any overlapping images. (DM-14670)
Answer: 120925.0

User story: "We no longer recommend the use of versions in the {{setupRequired}} or {{setupOptional}} statements in hand-written table files.  Those table files are automatically expanded to include exact versions when products are installed, which provides much more rigorous dependency version handling.  The version inequalities we used to include manually never provided much rigor, and provide none now that stack packages are versioned together."
Answer: 386.0

User story: "Test bare metal install, restart operation, and 2-day burn-in test. These tests are listed as DM L1 Image Ingest and Distribution tests #112 and #114, and can be found here:    [ATS Turnkey System Specific Tests|https://confluence.lsstcorp.org/display/JP/ATS+Turnkey+System+Specific+Tests]     "
Answer: 52228.0

User story: "We shouldn't need a StorageClass for every template instantiation of each afw.image class or every Config subclass (we don't have the latter, but only because of a hack).    Instead, we should store the actual pytype with with the Datastore and pass it to the Formatter for it to use."
Answer: 117684.0

User story: "To respond to LIT-390, produce a chart showing how our progress through milestones corresponds to the schedule."
Answer: 3.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: "This issue captures the effort spent on “supportive QA” over the S18 cycle. This largely consisted of working with various DM developers who required QA checks for their own work throughout the cycle. This often involved instructions on how to run the {{pipe_analysis}} scripts, descriptions on what plots are produced and identifying those most relevant for the particular issue, detailed descriptions of all the details included in the plots, and, on occasion, adding new diagnostic plots requested as useful by the developers. Specific examples include:   * getting Merlin F.-L. up and running with data processing and running on visitAnalysis.py script for quantifying his work on Brighter-Fatter corrections. Pointed out the diagnostics produced in that script most relevant to him   * getting Sophie R. up and running with the compare[visit/coadd]Analysis for her work with the data compression WG and others for her star/galaxy separation work   * added some diagnostic plots based on shape measurements at the request of Bob A.   * discussions about color locus diagnostics with Yusra A. for her artifact rejection in coadds work   * discussed diagnostics with John P. that may be relevant for his work on {{jointcal}}   * validating {{meas_mosaic}} outputs after John P’s PhotoCalib updates   * fielding queries from the DESC-SIMS folk who are running the scripts on their data products    Items not directly related to the {{pipe_analysis}} scripts:   * computing some rough detection thresholds for various fields of HSC data for Bob A. (I believe these were useful to him for his shear measurement experimentation)   * identifying very good seeing HSC visits by request of Josh M. for his PSF modelling work   * QA working group activities (meetings, brainstorming, obtaining feedback from DM experts outside of the WG, writing text on confluence pages)"
Answer: 3961.0

User story: "Implement one Jupyter widget"
Answer: 276689.0

User story: "BaseSkyMap now has a {{register}} method that adds that SkyMap to a Gen3 Butler repository (even on master - while this was originally an oversight, it does no harm there).  That code was broken by changes on master to other SkyMap APIs, so we need to fix this to sync the gen3-middleware branch up with master."
Answer: 116.0

User story: "Add scripts in xCAT to ensure that nodes:    (1) are automatically patched during deployment, and    (2) RPMs installed during deployment (by both xCAT and Puppet) come from managed repos to ensure consistent versions"
Answer: 45044.0

User story: "Get Puppet running on oradb nodes. Implement enough features to permit them to serve their purpose while also keeping them configured according to Security vetting process."
Answer: 45037.0

User story: "{color:#000000}Match what is already being done for NCSA 3003 systems, refactor code, make changes mandated by security vetting.{color}"
Answer: 265437.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: "pyprofit previously exclusively used libprofit to generate models; I added support for integrating and convolving with empirical PSFs using galsim. Analytic PSFs are a WIP.     Changes are mainly in make_model_galsim: [https://github.com/lsst-dm/pyprofit/blob/master/python/profit.py]    Pycharm run configurations for HSC tests are available here; this will be kept up to date (see DM-14647):    [https://github.com/lsst-dm/pyprofit/blob/master/.idea/runConfigurations/pyprofit_fit_hsc.xml]    At the time of writing, the command to run the HSC example is    python3 $PROJECT_DIR$/examples/hsc.py    Galaxy cutout arguments:    -radec 134.67675665 0.19143266 -size 19.9asec    Enable galsim:    -galsim 1"
Answer: 30020.0

User story: "I wrote an example script to download HSC images with the quarry tool and PSF images from the picker tool and fit them. This is available at [https://github.com/lsst-dm/pyprofit/blob/master/examples/hsc.py] . I attached an example of an r-band fit to a GAMA galaxy from HSC-wide. This is meant as a publicly-available precursor to integration with the stack - it's not very useful on its own since the footprints aren't publicly available, but could be expanded to test other deblenders like Scarlet.    Pycharm run configurations for HSC tests are available here; this will be kept up to date:    [https://github.com/lsst-dm/pyprofit/blob/master/.idea/runConfigurations/pyprofit_fit_hsc.xml]    At the time of writing, the command to run the HSC example is    python3 $PROJECT_DIR$/examples/hsc.py    Galaxy cutout arguments:    -radec 134.67675665 0.19143266 -size 19.9asec    There are further options enabled in other tickets like galsim integration (DM-14648) and other optimizers (DM-14635) but the defaults should always work as long as a cutout is available at that location."
Answer: 90481.0

User story: Attended the workshop "Data Visualization in the Era of LSST"  held at NCSA, 6/19-21.     Gave a talk about Firefly and demoed the new feature of HiPS image display.         http://www.ncsa.illinois.edu/Conferences/LSST18/
Answer: 36011.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: * Participated in a Jupyterlab tutorial, a Jupyter widgets tutorial, and a PyViz tutorial covering Holoviews and Datashader.   * Sprinted on a ginga widget with Eric Jeschke (ginga lead), Pey Lian Lim (JWST ginga lead and Astropy core dev), and Matt Craig. Eric made experimental branches of aggdraw and ginga to show how drawing circles could be vectorized to improve performance.   * Hacked on a Firefly extension for Jupyterlab (experimentally).   * Participated in Bird of a Feather session on dashboards and plotting, with a panel of representatives from Plotly, ipywidgets, and Holoviews/Bokeh.   * Attended many exciting visualization talks on ipywidgets for Plotly (Jon Mease), 3-D rendering in Jupyterlab (Maarten Breddels), and other widgets in Jupyterlab (Sylvain Corlay).   * Discussed visualization with various experts including Jason Grout (Bloomberg/Jupyter), Paul Ivanov (Bloomberg/Jupyter), Jon Mease (JHUAPL), and Maarten Breddels.   * Presented a non-LSST talk "Practical Applications of Astropy".
Answer: 76048.0

User story: "Add a {{transaction}} context manager to {{Butler}} that uses {{Registry.transaction}} and {{Datastore.transaction}} to make multiple {{put}} calls optionally transactional (rolling back in case of failure)."
Answer: 20339.0

User story: "Add a {{transaction}} context manager to enable multiple {{put}} calls to be handled as a single transaction (either all working or not at all)."
Answer: 20331.0

User story: "Tractor ([http://thetractor.org|http://thetractor/], [https://github.com/dstndstn/tractor/]) is a python/C++ package for Bayesian source modelling, much like ProFit ([https://github.com/icrar/ProFit)|https://github.com/icrar/ProFit).]. However, Tractor has a number of extra useful features, including support for multi-band fitting, integration with astrometry.net and built-in descriptions of multi-component models. I installed Tractor and adapted the existing SDSS test to fit HSC images via the quarry tool ([https://hsc-release.mtk.nao.ac.jp/das_quarry/|https://hsc-release.mtk.nao.ac.jp/das_quarry/)]); the script is attached. Unfortunately, I found Tractor to be rather sparsely documented and not entirely intuitive to use, with custom optimizers that would be difficult to maintain. Furthermore, it has a lot of python2-isms and some C++ code wrapped with Swig which would require significant effort to make compliant with LSST standards, and so I don't think it's worth pursuing further. It may be worth contacting the Tractor authors (mainly Dustin Lang), though."
Answer: 40436.0