udaykiran19491/user-stories-from-tawos-for-llm-fine-tuning huggingface dataset:
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "At some point we need to convert LDM-151's reference to use bibtex; right now I'm just adding TODO notes for any references I'd like to add instead of going through the pain of adding them manually.    I'm assigning this to [~<USER>, with the expectation that he'll assign it to someone else once he determines its priority.  "
Answer: 409417.0

User story: "[Line 288 in {{detection.py}}|https://github.com/lsst/meas_algorithms/blob/554ea72d0c0a83ccceb62fbef5f6807ffc47530b/python/lsst/meas/algorithms/detection.py#L288] defines the alias {{makeSourceCatalog}} for the run method of the {{SourceDetectionTask}} and notes that the alias is deprecated and should be removed after checking for current usage.  Remove the alias definition after checking to ensure that the alias is not used anywhere in the stack.    Example of current usage in the stack (NB not complete!):    # [pipe_tasks - {{multiBand.py}}: The {{runDetection}} method of {{DetectCoaddSources.py}} (line 280)|https://github.com/lsst/pipe_tasks/blob/a43c408a0c5653160b8646e622e4adecaeee4232/python/lsst/pipe/tasks/multiBand.py#L280]."
Answer: 2271737.0

User story: "Instead of producing short-period (e.g. yearly) coadds for the purpose of detecting and characterizing faint, slowly-changing sources, I believe we should diff these coadds against a full-depth coadd (or perhaps each other), and detect and characterize on the difference images.    This should reduce blending issues in characterizing these objects, and it should make what I'm calling the DeepAssociate pipeline (where we merge Footprints and Peaks to define Object candidates, just before deblending) much easier, because the short-period coadds will no longer contribute redundant detections for static sources at single-year depth.    I thus far have not included this proposal in LDM-151, in order to maintain consistency with the DPDD."
Answer: 283780.0

User story: "If a user has a version of matplotlib installed from a git clone, the eups dummy package fails at the matplotlib version check. The versioning scheme for this type of install is determined by pep 440. Make the configuration script handle this type of version comparison."
Answer: 1203.0

User story: "When iterating a psf in a single frame processing for ci_hsc data-product visit 903338 ccd 18, the psf determiner generates a PSF for which a shapelet approximation cannot be found. Specifically, when the PSF determination stage iterates, it converts the determined PSF from the previous step into a Gaussian with an equivalent width. The double shapelet approximation fails to fit this Gaussian.    This ticket should make the PSF fitting robust against cases like this. Additionally it should revert the changes in ci_hsc on the DM-4202 ticket branch which were put in as a temporary workaround for this problem.    Attached to this ticket is the PSF that is failing, and a script which can reproduce the problem."
Answer: 202957.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: "HSC currently has a definition file for defects consisting of  {code}  #CCD x0    y0    width height  {code}  (this is then converted to a binary file for efficient application to the data).    We need to define a similar file format for the use of all cameras.  The format can be different (yaml?), but it also needs to add some extra fields;  enums that define the type of the defect (e.g. trap, serial trap, hot pixel, ...) and the action to be taken, and some parameters (e.g.trap lifetimes).  We will also have to write code to make use of this information.    This format needs to be defined in conjunction with the camera team."
Answer: 164058.0

User story: "Per review of DM-6532, this material should live in DMTN-020:    {quote}  +As explained above, epics are used for planning and executing work within a cycle.   +   +In addition to that, epics are also extremely valuable for longer-term planning at a fine-grain level.   +When details of work for a given planning package are known, they can and should be captured through   +epics. Such epics can be freely created and changed at any time without any approvals. They   +should, of course, fit within the scope and budget of related PP. They can be useful for   +bottom-up analysis and validation of resources needed to implement a given PP. This allows   +to do detailed planning in flexible and agile way, while ensuring the scope/cost/schedule is   +well controlled and managed.  {quote}"
Answer: 11124.0

User story: "Per discussion in DM-6532, this material is appropriate for DMTN-020:    {quote}  +It is acceptable to load the plan in 3-month chunks, e.g., the plan for   +the first 3 months of the cycle is loaded before the start of the cycle, and the remaining   +part of the plan covering the last 3 months is loaded before the 4th month starts. This   +allows for minor fine-tuning of the second half of the cycle without going through the CCB   +approval.  {quote}"
Answer: 11134.0

User story: "Capture the policy for releases (all work to be done 2 weeks before end of cycle, release at the cycle changeover) in DMTN-020."
Answer: 237340.0

User story: "See notes at https://confluence.lsstcorp.org/display/DM/ProjMgmt+Meeting+2016-06-14"
Answer: 139167.0

User story: The queryId, "QI=xxx:", needs to be added to log messages that are useful for analysis. of primary interest are messages that indicate that a query has begun or finished, such as "Discarded UserQuerySelect".
Answer: 30439.0

User story: "How to load data and perform queries.  Investigate DAX interface to qserv."
Answer: 24287.0

User story: "Transcribe v12_0 release notes prepared by development teams on Confluence into the Pipelines documentation sphinx project.    Pipelines documentation is published with LSST the Docs to https://pipelines.lsst.io."
Answer: 1702.0

User story: "Currently, when external viewer launched, it is blocked by pop-up blockers. Need to change polling logic to a pushed solution so the 'launch' action can happen immediately. "
Answer: 3421.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 shared stack on {{lsst-dev}} (etc) currently only provides tagged weekly builds of the LSST stack. Releases, RCs, etc are not included. Please update the build script so that they are.    NB simply including these builds is easy enough by changing the {{VERSION_GLOB}} regular expression in {{shared_stack.py}}. However, the {{current}} version is selected by a lexicographic sort of available versions. That works well enough for weekly builds ({{w_2016_XX}} is less than {{w_2016_XX+1}}), but fails with other tags. Better use a sort based on the date the tag was created on the HTTP server instead, perhaps."
Answer: 4410.0

User story: "Qserv uses Docker for deployment, this ticket will add track on how to improve container deployment and management."
Answer: 82813.0

User story: Update DMBP and DM projects based on decisions made through ProjMgmtWG:    DMBP  * remove planning packages  * milestones need WBS  * add field to Milestones: "planning package key"    DM  * add to epics a field "planning package key"  * add fields "TCAM1" and "TCAM2" to all issues  * add fields: reviewer #1, reviewer #2  * tweak workflow for epics:  ** must have reviewers assigned before epic switched to "in progress"  ** reviewers must sign off the review before epics marked "done"      I think it'd be also useful to have a brief description of milestone levels on the "edit issue" page (visible to NSF, cross-subsystem, cross-team, internal to one team)    I assume we will transfer KPMs from DLP to DMBP as-is, when is the best time to do that?  
Answer: 2025722.0

User story: "Write a technote describing the analysis and implementation of the Lupton(ZOGY) difference image decorrelation correction.    A new technote has been set up, it will be: http://dmtn-021.lsst.io"
Answer: 113751.0

User story: "DRP will be able to measure proper motion and parallax better than we can in AP.  Additionally, the baseline for measuring parallax will be about the same as the initial data release.    This issue is to follow up about whether it is actually useful to calculate those quantities in AP at all.  We could potentially just use the DRP numbers."
Answer: 165773.0

User story: "We currently have 73 milestones scheduled for F16 (see the list [here|https://jira.lsstcorp.org/issues/?filter=14309]). While it is true that we will be revisiting milestones when we finalize replanning, there is no point in keeping any milestones open with due date in F16 if we already know they won't happen, so I am asking TCAMs to revisit them and update: delete these that no longer make sense, or push these that you are not planning to deliver in F16 into future cycles. Please keep only these milestones scheduled for F16 that you are going to deliver."
Answer: 655403.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: "At least one developer hadn't realised that the Buildbot system at http://lsst-buildx.ncsa.illinois.edu:8010/builders/DM_stack is now deprecated and they should be using Jenkins instead. Of course, that's clear when reading the Developer Guide, but that isn't clearly linked from the Buildbot pages. Assuming we can't just remove the Buildbot pages altogether, it would be great to add a prominent note to them directing developers to look elsewhere."
Answer: 347576.0

User story: "Add a requirement for an N-way matcher to LDM-151."
Answer: 42.0

User story: "Adding text to LDM-151 where appropriate, working around the structure defined by Jim et al."
Answer: 2890.0

User story: "Write LSST DM Project Management and Tools document ([LDM-472|http://ls.st/LDM-472])"
Answer: 138254.0

User story: "We are doing poorly with dealing with action items from past meetings.  Looking at Feb JTM:    https://confluence.lsstcorp.org/display/DM/DM+JTM+2016-02+Meeting+Notes    17 out of 21 are not done.    Looking at the latest: DMLT F2F    https://confluence.lsstcorp.org/display/DM/DM+Leadership+Team+Meeting+2016-05-16+to+19%2C+Face-to-Face    ~35 out of ~50 are not done.    Could TCAMs review these actions, follow up with your team and deal with them?    I’d suggest to turn still-open actions into stories in jira."
Answer: 607944.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 ProjMgmt WG is going to agree on a strategy for long term planning. Make sure it's captured in DMTN-020."
Answer: 521822.0

User story: "We should make this page: https://confluence.lsstcorp.org/pages/viewpage.action?pageId=21397653 obsolete once the DMTN-020 is done."
Answer: 243978.0

User story: "Based on branch u/ktlim/getLogger in {{log}} and requests from DM-3532, implement a lsst::log Python interface through Log objects, and allow controllability of logger names and levels in Python.  "
Answer: 57454.0

User story: "Summarize RFC-29, evaluate technical details, prepare working examples, re-raise RFC-29 or file a new RFC before the migration.  Some implementation may be done before the new RFC.  "
Answer: 70413.0

User story: "Locking tables in memory with mmap and mlock greatly increases scan query speeds but makes the worker scheduler unresponsive to interactive queries. This also tends to have only one scheduler (fast, slow, medium) running at a given time."
Answer: 25899.0

User story: LSST fftw and numpy 'mkl'-version have namespace collisions, on linux machines. Therefore the LSST build requires a nomkl version of numpy + friends. However, on macs the 'nomkl' option is not necessary and should not be there.    [~<USER> suggests that lsstsw/bin/deploy should be fixed to avoid using nomkl on macs.     It would be good to fix this throughout our distribution schemes though - conda has a (self-described by [~<USER>) "horrible hack" which should avoid this in future conda releases.     I'm not sure what happens with eups distrib releases, where miniconda is installed first.     But anyway - it would be good to fix this across the board.
Answer: 482170.0

User story: "Convert the footprint support from the GWT code"
Answer: 58151.0

User story: This code seems obsolete and unused:    {code:bash}  qserv@clrinfopc04:~/src/qserv (tickets/DM-5967)$ grep -r "version.h" *  admin/tools/docker/git/src/qserv/site_scons/genversion.py:# genversion.py : declare a builder for global version headers.  admin/tools/docker/git/src/qserv/site_scons/genversion.py:    """Construct a version header from git-describe output and store  admin/tools/docker/git/src/qserv/core/modules/SConscript:versionFile = env.Command(['global/version.h'], None, genversion.buildVersionHeader)  core/modules/SConscript:versionFile = env.Command(['global/version.h'], None, genversion.buildVersionHeader)  {code}
Answer: 1945640.0

User story: I am asking all TCAMs to review [The Team|https://confluence.lsstcorp.org/display/DM/The+Team] page and add missing pictures of all members of your team. Please remove your name from the reviewers' list when done. The last person should mark it "reviewed"
Answer: 716724.0

User story: "This follows on from  [DM-5315] and covers collating comments from DMLT, submitting the status report and document to Systems Engineering and dealing with the comments.     "
Answer: 15.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: Per RFC-24, the System Architect is the BDFL for "the Coding Standards document": he is ultimately responsible for approving or rejecting all changes suggested.    But: what is "the Coding Standards document"? There are several "Coding Guides" listed [part of the Developer Guide|https://developer.lsst.io/#part-coding]. [Some of them|https://developer.lsst.io/coding/cpp_style_guide.html] are marked with specific notices that changes must be approved by the System Architect; [others|https://developer.lsst.io/coding/using_cpp_templates.html] aren't. Are they all covered by the RFC-24 provisions? Should they be?    Once the above is clear, please document this policy somewhere obvious (perhaps in the [introduction|https://developer.lsst.io/coding/intro.html]?), so that folks who are proposing new pages (rather than simply editing existing pages) will understand the policy.
Answer: 362804.0

User story: "Review [Swift|http://swift-lang.org/main/index.php] scripting language against criteria defined in the epic."
Answer: 32925.0

User story: "Review Pegasus Workflow Management System (https://pegasus.isi.edu) against criteria defined in the epic."
Answer: 32925.0

User story: "Need to decide what to check so we have a consistent testing, requirement is opensource  - language  - license  - maturity  - funding  - ease of install  -- dependencies  - OS requirements  - ease to create a workflow  - ability to execute on clusters/laptop  - test with simple LSST workflow  - willingness to meet and answer our questions  -- open bug reporting site  -- speed at which bugs are resolved  -- size of community, external collaborators  - how big a graph can it support?  - is shared filesystem required for data, or can it take care of data transfer  - does it support MPI other parallel code?  - smart wrt to data available on node (optional)  "
Answer: 17390.0

User story: "When compute the points for the grid lines, there is no guarantee that the number of points will all be the same.  However, the points can be regrided to ensure all the lines have the same number of points.  Xiuqin also reported that the label is not correct in some cases, such as position 45 89, WISE image grid."
Answer: 485634.0

User story: "Convert irsaviewer to use the new firefly library built on react/flux.    also made these changes:  remove irsa footer from fireflyviewer  filter by selected rows  auto-correct table’s filter input.  multiple columns sort via sortByCols  fix menu item not showing selected  ife automatically builds firefly.    To test, make sure you pull ife repos as well.  same branch name on ife."
Answer: 10044.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: "Per mail from [~<USER> to the DMLT of 2016-06-07, individuals who are funded to attend a meeting by LSST are obliged to provide a meeting report when one is requested via JIRA issue.    A list of all meetings and attendees is available at https://confluence.lsstcorp.org/display/DM/DM+Meetings.    Please ensure this policy is documented somewhere appropriate. (Does it belong in the Developer Guide alongside topics like Team Culture?)"
Answer: 514479.0

User story: "[~<USER> has written a code to automate Qserv cluster boot on Openstack cloud. Soma support was required to understand and solve cloud-init and openstack issues, Qserv container deployment and LSST coding standards."
Answer: 40539.0

User story: "Bogdan Vulpescu, IN2P3 engineer, tried to load DC2013 data sample. Fabrice help was required to install Qserv in multi-nodes and understand data-loading system.    Some issues have been found and will be reported in future tickets:    - a script to publish loaded data (i.e. insert db name in qservw_worker.Dbs) would be useful  - mysql client might break proxy if option are not provided correctly (a bug report will be available soon)"
Answer: 194328.0

User story: "We have UKIRT+WFCam observations we want to combine with HSC.  To start that, we need an obs_ukirt package with a {{WfcamMapper}}.  The data presented to the observer have been processed through the equivalent of ISR, but still need photometric and astrometric calibration."
Answer: 1893890.0

User story: DM-6490 reports on an offset between the calibration zeropoints between HSC vs. LSST *processCcd.py* runs.  Here we report another, additional, offset seen in certain HSC visits.  It is not seen in the figures shown in DM-6490 for visit 1322.  However, here attach the same figures for visit 19696, run with identical setups/configs for both stacks as in DM-6490, where we see an additional offset in the "common ZP" figures (i.e. all fluxes have been scaled the same zp=33.0 for comparison).    A best guess at present is that the calibration frames are different between the HSC and LSST stacks for the timeframe of this visit; e.g. were the inputs ingested exactly the same for both sets?  Did the bug in regards to flagging on the flats noted in DM-5124:  {quote}  I found a difference in the codes doing the statistics: the HSC code uses a hard-coded mask ignore list of DETECTED only, while the LSST code uses a configurable mask ignore list that defaults to DETECTED,BAD (and the default isn't overridden). This produces a large difference on CCDs with bad amps (e.g., ccd=9).  There's a smaller difference on ccd=49 because the number of BAD pixels is smaller. Also note that the scaling of one CCD (like ccd=9) can affect others because we force the normalisations to correspond to that which we get from solving the system of M exposures of N CCDs.  {quote}  have a greater impact on these calibs?    Please investigate the cause of this offset.
Answer: 33228.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: "Recent changes in 'dev' made some of the components stop working.  We need to click through firefly viewer to identify the problems and fix it.  Below are a few that I've spotted.    Data Sets menu:  Form fail validation when they should not.  filters and upload file should be nullable.    Catalogs Classic menu:  form fail validation without any visual indications.  valid parameter is false when passed into validUpdate in CompleteButton.    xyPlot(Scatter Plot) options:  Beside X and Y, everything else should be optional(nullable).  Even after entering a valid value into all of the fields, 'OK' still fail validation similar to above where 'valid' parameter is false when passed into CompleteButton.    There may be more, please do a quick search to make sure all usage of CompleteButton is good.   "
Answer: 62058.0

User story: "This needs to be worked around by either using a different version of conda-build or addressing the changes to the conda recipe structure. I also want to comment and/or create an issue on conda-build so they know that such changes are affecting users.    See:    https://github.com/conda/conda-build/issues/1003  https://github.com/conda/conda-build/pull/1004    https://github.com/conda/conda-build/commit/b4ec0e0659d8f376042d4fc391616bf235996cf5    [Mario fixed it|https://github.com/<USER>conda-lsst/commit/6a552b6f9cada2530681cfdc4a9f67add261ff99] but that fix will be broken as soon as conda-build #1004 is merged."
Answer: 225895.0

User story: "[~<USER> requests that conda-lsst uses Conda's psutil. Currently we use our own version."
Answer: 348255.0

User story: "Restore the registry for star selectors that was lost in DM-5532, now that tasks in registries can be used as subtasks.    Also use the registry where appropriate."
Answer: 9610.0

User story: "Image Meta Data tab  * images cannot be remove, but in expanded mode, it can.  * selecting image no longer highlight table.  the reverse works fine.  * visualize/saga/ImageMetaDataWatcher.js:272 returns -1.  * when a non-meta table is selected, images are shown, but not the toolbar.  * after table is removed, images are still there.    image external api does not mix well with firefly viewer.  * firefly viewer uses 'triViewImages’ viewer_id while api has no viewer_id.  as a result, images loaded by api will be lost once table or other searched data are returned.    * catalog overlay are drawn outside of the images.    more issues:    - -It's possible to select distance tool and then area selection. First drag would define area selection, all the following line. A click would be defining a 0 length line, even if point selection is enabled.- _moved to_ DM-6656  "
Answer: 86159.0

User story: "In order to restrict the jenkins aws credentials to only being able to create new snaphots, a mechanism is needed to handle purging old snapshots that is external to jenkins."
Answer: 948943.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 [~<USER> attempted to use the Conda repository he ran into a problem installing and using the packages because he already had an active EUPS_DIR and EUPS_PATH.    When the eups package is installed and linked, it should warn users when these environment variables are set.    I'm open to another solution but would prefer it doesn't change the eups package behavior. Changing behavior goes against the best practices for Conda and more generally packaging."
Answer: 11503.0

User story: "At present, this job is being templated by puppet to inject the keys in plain text which are they converted by jenkins to stored secrets if/when the job is edited and resaved via the jenkins UI.  This means that the credentials may be leaked."
Answer: 10355.0

User story: "The *.lsst.codes wildcard cert in usage is about to expire."
Answer: 327.0

User story: "The version of nginx has been free floating and this caused warnings/errors in the 1.9 -> 1.10 transition when the {{spdy}} keyword was renamed to {{http2}}."
Answer: 80729.0

User story: "In DM-5827, [~<USER> wrote:  {quote}  In most of these plots you can see some scatter at relatively bright magnitudes... These are likely getting different pixel values when we replace objects with noise which is causing these changes.  {quote}  Check that this is the case, and, if so, explain why the noise replacement is different."
Answer: 20136.0

User story: "The previous comparison of coadds on HSC and LSST was performed without an operable LSST-based meas_mosaic. When one becomes available, demonstrate that mosaicking is consistent between HSC and LSST; describe, account for, and (where possible) correct differences."
Answer: 43079.0

User story: "Demonstrate that the HSC and LSST stacks produce consistent results for Kron measurement. Account for (and fix, if relevant) any differences."
Answer: 34790.0

User story: "Demonstrate that the HSC and LSST stacks produce consistent results for CModel measurement. Account for (and fix, where relevant) differences."
Answer: 54958.0

User story: "For all the stories describing comparisons between HSC and LSST results (notably DM-5301 and DM-5827), please provide instructions describing the steps to reproduce the comparison. In particular, include:    * A list of any tweaks that had to be applied to the code;  * Non-default configuration options;  * Exactly which comparisons were made."
Answer: 135390.0

User story: "After RFC-184 is closed: implement, unit tests, review, document, submit.    When this story closes, I think RFC-184 status is supposed to be changed from Adopted to Implemented."
Answer: 66376.0

User story: "We need to flesh out the skeleton text to contain full descriptions of the algorithms and pipelines we expect the baseline design to use."
Answer: 24678.0

User story: "Drive the RFC for Repo Refactor to completion (this includes a lot of design work)"
Answer: 8448.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 APIs for the storage brokers we're looking into are similar, but don't have a 1-1 correspondence.  Write up the features offered by the APIs, and see where there is overlap."
Answer: 36129.0

User story: "An initial version of DMTN-020, describing project management practices, was produce in DM-6140. Revise and update that based on feedback from the DM Project Manager, DM Project Controls Specialist, DM technical managers, and others."
Answer: 40442.0

User story: "Measure the photometric and astrometric precision for the DECam COSMOS dataset and determine the sources of extra systematic scatter."
Answer: 8.0

User story: "Complete Ansible implementation started in DM-6388."
Answer: 231925.0

User story: "After the code is tested remove the GWT from the build. Should check with [~<USER> to make sure the boolean to enable GWT has been removed from VisUtil.js and WebPlot.js"
Answer: 76402.0

User story: "Now that the gwt algorithmic code has been converted it needs to be validated. Set up the test for both the projections routines and the coordinate conversion routines.    h3. Task Details  * Unit test should be run on the Java and JavaScript side  * A unit test should exist for all 10 projections. More might be necessary since there are variation within a projection type.  * We need to bring Booth in for details of each projection and each variation.  * Booth has example file somewhere.  * Xiuqin ran coordinate conversion test in to past.  She (and maybe Booth) have the best understand of what that test should be.   * The same input file should be used for the Java and JavaScript side.  * The same output (if possible) should be produced.      h3. Status so far    *Projections*    * GNOMONIC - somewhat tested  * ORTHOGRAPHIC -somewhat tested  * AITOFF - somewhat tested  * SFL - somewhat tested  * PLATE - somewhat tested  * LINEAR  * ARC  * CAR  * NCP  * CEA      *Coordinate conversion.*    It appears to work when run in Firefly, however the code is not fully covered.    h3. Switching between GWT and pure JavaScript    To switch between GWT and JS edit {{VisUtil.js}} and change the following line:  {{export const USE_GWT= false;}}    true uses the old code, false used the new code.    h3. Entry Points and Directories      * Coordinate Conversion:  _Dir_: firefly/src/firefly/js/astro/conv, _Entry Point:_ VisUtil.js, convert(), line 104, also see line 26  * Projection: _Dir_: firefly/src/firefly/js/visualize/projection, _Entry Point:_ WebPlot.js, makeWebPlot(), line 124  "
Answer: 168285.0

User story: "convert Booth's projection code and Judy Bennet's coordinate conversion routines to pure javascript  "
Answer: 5451.0

User story: "Object store investigation report"
Answer: 129598.0

User story: "Additional sites and/or simulation using WAN emulation techniques."
Answer: 129600.0

User story: "Commission the evaluation framework on one machine at NCSA."
Answer: 129602.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 ticket relates to attendance at the SPIE meeting in Edinburgh the last week of June."
Answer: 42491.0

User story: "Investigate observation model interfaces and storage, and applicability of CAOM"
Answer: 282480.0

User story: "DM-5695 will create transfer matrices stored as numpy arrays. This ticket extends that work to determine a useful format and write functionality to persist those arrays."
Answer: 148228.0

User story: "Implement containerized DAX services"
Answer: 213192.0

User story: "https://github.com/lsst-sqre/post-qa/pull/1 Josh notes that post-qa should not assume the Git repo URL pattern for a stack package.    bq. There are a currently a few packages in repos.yaml under the lsst-dm org. This is fine for now but it would be safer to either look at the repo's remotes or lookup the url from repos.yaml.    "
Answer: 194195.0

User story: "For all subsections in  Algorithms Components owned by [~<USER>:   - Provide enough bullet points to capture scope.   - Add bullet points for subtly difficult aspects of components.   - Add extra level subsubsubsection level for Measurement.   - Create matrix of measurement algorithms and contexts.  "
Answer: 2571.0

User story: "Work 90% complete already from live meeting; just need at ticket number for the branch."
Answer: 13.0

User story: "Using my AP prototype script produce some performance numbers and plots for L1 database operations. Do it for baseline schema as defined in current baseline (cat package) and also try to get somewhat improved mysql schema (I know already that baseline indices do not work very well for Object table)."
Answer: 128273.0

User story: "I will be useful to compare MySQL and Postgres performance for use in L1. After DM-6918 is complete (means works with MySQL) verify that it can also run against Postgres. "
Answer: 87688.0

User story: "To enable Python 3 support of the stack the EUPS {{python}} stub package needs to allow Python 3.    "
Answer: 91071.0

User story: "Placeholder for L1 database prototyping in June 16 -- to be replaced with actual stories of same sp total"
Answer: 42199.0

User story: Implement RFC-185 by updating the "Using Boost" section in DM Developer Guide to prefer standard library by default.
Answer: 2882.0

User story: "In order to move A.net out of meas_astrom to make it a true dependency, we need to replace its use in tests."
Answer: 80665.0

User story: "We need to flesh out the algorithmic components and narrative sections to the point of having ~1 sentence per paragraph in the finished document."
Answer: 4253.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: "Camera geometry used to be defined using PAF (policy) files, which are now deprecated. As part of the transition to the refactored camera geometry scheme, scripts were introduced to convert from the PAF files to the new camera geometry configuration scheme which uses FITS files and a python file to describe the camera. These scripts are still part of the obs_* packages, and some people rely on them for making changes to the camera description. On the other hand, the generated FITS files and python file are also first-class members of the obs_* packages. This means that we have two sources of the same information, which is dangerous.    For obs_lsstSim, obs_decam, obs_cfht and obs_sdss, we want these scripts to be the primary source of information.  This means we should delete the generated files, and create them at build time.  We should also standardise the name of the script used to generate these."
Answer: 1423037.0

User story: "PAF files have long been deprecated, but continue to be used for describing the camera geometry.  We need to replace the PAF cameraGeom files used for CFHT-MegaCam, DECam, LSSTSim and SDSS, and the scripts used to convert these files to FITS files for reading by the Mappers.  They might be replaced by a configuration like YAML, or pure python."
Answer: 1423038.0

User story: "Write photometric calibration pipeline section of LDM-151"
Answer: 143586.0

User story: "DM-4009 added the C++ and swig changes needed to allow the FlagHandler to be used from Python.  During review, Nate suggested that a decorator class could be used to improve the use of this code in Python.  This ticket will be to review Nate's decorator and confirm that it is the correct model for Python-only plugins.    We will also modify the unit test in DM-4009 and the EmPsfApprox plugin in DM-6123 to use the decorator."
Answer: 17219.0

User story: "Create documentation for the Stack conda binaries created in DM-5415 as part of the Science Pipelines documentation"
Answer: 3248.0

User story: "Python API to use Firefly visualization components and other functions.   This story is to come up with a good plan for the rest of the development work to related to Python API.     Decision:  First version: We will expose all the JS API through Python API. As we expose more of JS API to public, we will develop the Python API so they are in sync."
Answer: 153428.0

User story: "Some proposals made on DM-6247 to change the structure of LDM-151 (add Algorithmic Components section, move overview into production-specific sections, add notation section to introduction) were accepted at the live meeting on 6/27.  This issue rewrites the introduction accordingly."
Answer: 1715.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: "From [~<USER>'s [technical debt list|https://confluence.lsstcorp.org/display/~<USER>DM+Technical+Debt]:  {quote}  We need to be releasing the GIL when we go from Python to C\+\+, we need to audit our C\+\+ code to make sure it actually is thread-safe, and we need to add OpenMP parallelization for at least trivial low-level operations (e.g. image addition), even if we don't use it most of the time.  {quote}  My best guess is that this is 2 FTQ.  "
Answer: 185916.0

User story: "From [~<USER>'s [technical debt list|https://confluence.lsstcorp.org/display/~<USER>DM+Technical+Debt]:  {quote}  afw.geom and sphgeom don't interoperate with each other, WCS, or cameraGeom, and we have no overall vision for how they should. They should also have much more consistent interfaces.  afw.geom has a clunky Python interface, and Polygon doesn't really fit into the library well.  {quote}  My best guess is that this is 4 FTQ, but best split across at least two developers (from Science Pipelines and Data Access) and multiple cycles, as some work may be blocked by getting sign-off on the design from the broader team. Also,  {quote}  Astropy is just starting to think about how to integrate various geometry concepts into a single interface. If we act now and get invested in that design, we can leverage a significant amount of quality-developer time from the Astropy community. If we don't get involved now, what they produce will be unlikely to meet our needs.  {quote}  "
Answer: 185993.0

User story: "While the Data Access team has taken ownership of the new logging package, no one has taken ownership of converting old Science Pipelines code to use the new package and removing the old one.    Probably 1 FTQ at most."
Answer: 185989.0

User story: "From [~<USER>'s [technical debt list|https://confluence.lsstcorp.org/display/~<USER>DM+Technical+Debt]:  {quote}  We've identified simple and unambiguously popular ways to improve our Python interfaces, like adding properties, and there are many more not-just-Python improvements that can be made to specific classes just by looking for clunky interfaces without assuming they're set in stone.  Currently, downstream code is becoming more reliant on interfaces that we'd ultimately like to change. We're embarrassed to show code samples to outside developers, and have to warn new users that they cannot expect interface stability, discouraging adoption.  {quote}  My best guess is that this is approximately 0.5 FTE, ongoing, but it may be best done by reserving a small fraction (10%) of several developers' time.  "
Answer: 185991.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: "From [~<USER>'s [technical debt list|https://confluence.lsstcorp.org/display/~<USER>DM+Technical+Debt]:  {quote}  There is no clear ownership for the successor to the afw.display tools. SUIT has expertise and related work already planned but no mandate and a very different timeline than what's needed here; SQuaRE and Science Pipelines perhaps have a better idea of requirements, and all three need to share low-level components.  This is not just visualization; we also need to someone to think about cleaning up lsstDebug system and figuring out how/if that integrates with logging, as well as ensure that a number of low-level afw classes (images, tables) are usable from the visualization tools and tightly integrated with them.  Currently, Science Pipelines developers individually implement their own throw-away tools. Developers are inclined to ignore scientific implications of code and algorithm changes because the overhead involved in inspecting them is too large.   {quote}  My new best guess is that this is between 2-3 FTE, ongoing, and it became clear at the DMLT F2F that no team currently considers this part of their mission.  The best way to start may be a 2-3 day technical meeting to define requirements.  If we can't make that happen before long-term planning is complete, we need to make sure we at least guess at how much effort it will be.  "
Answer: 185969.0

User story: "From [~<USER>'s [technical debt list|https://confluence.lsstcorp.org/display/~<USER>DM+Technical+Debt]:  {quote}  Current package organization is ~50% historical, making it hard for new users to understand. We've never settled whether we define packages as namespaces (to group similar code) or in order to sanitize dependencies, and our indecision shows. We need more sensible entry points (metapackages? tags?) for different flavors of user/developer, and someone to think hard about how to handle different classes of extension package and optional dependencies.  It's too hard for new users/developers to find the package that contains certain functionality, and too many large-scale user-visible structures are being defined an a completely ad-hoc fashion.  Progress probably needs to be incremental, not big-bang, but we need a long-term vision for where it's going.  {quote}  My best guess is that this is 0.5 FTE, ongoing.  "
Answer: 185962.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: "From [~<USER>'s [technical debt list|https://confluence.lsstcorp.org/display/~<USER>DM+Technical+Debt]:  {quote}  As we start having both development and long-lived stable branches, we need someone in charge of vetting what goes into a release in terms of both testing and declaring feature/code freezes. This also includes managing shared software stacks. Until package framework improvements makes this a one-button operation, we also need someone to actually shepherd that process.  Major releases are not useful for developers, and weeklies are hard to track; need feature-based releases with meaningful version numbers  {quote}    My best guess is that this is 0.25 FTE, ongoing.  "
Answer: 185955.0

User story: "From [~<USER>'s [technical debt list|https://confluence.lsstcorp.org/display/~<USER>DM+Technical+Debt]:  {quote}  eups and eups distrib (or whatever we use instead) need an active developer who can work towards generally improving them (consider link farms, integration with pip/setuptools, faster databases) rather than just putting out fires.  The stack is too hard to install, and to hard to develop on even for experts.  {quote}  As discussed at the DMLT F2F, a major concern is giving the maintainer technical agency (including potentially moving beyond eups) within the requirements.  Most immediate task may be to ensure requirements are fully specified and distinguished from the current designs of eups and eups distrib.    My best guess is that this is 0.5 FTE, ongoing.  "
Answer: 185988.0

User story: From [~<USER>'s [technical debt list|https://confluence.lsstcorp.org/display/~<USER>DM+Technical+Debt]:  {quote}  Data product naming consistency and relationships are a mess, and data products are poorly defined (in the code, not in the future envisioned by the DPDD). Retargetable Task interfaces are poorly specified. As parallelization increases, things will only get more complex. We need someone to think about versioning and aggregating data products beyond just providing support for them in the Butler.    Our most user-visible interfaces are poorly defined and poorly documented. Even big overhauls like ProcessCcdTask are locally reasonable but must make undesirable compromises to fit into larger system.  {quote}  The LDM-151 rewrite will include a much of the design work, making this job more about implement that refactoring (with placeholders) and ensuring it remains reasonable (and consistent with LDM-151) as algorithms change.    This work has significant overlap with the role of a "Data Flow Scientist" identified in a recent review.    My best guess is that this is 0.5 FTE, ongoing.  
Answer: 186016.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: "From [~<USER>'s [technical debt list|https://confluence.lsstcorp.org/display/~<USER>DM+Technical+Debt]:  {quote}  Need maintainer to oversee obs_ package consistency and code reuse in defining ISR, calibration products generation, and reading raw data. Should take at least partial ownership of CameraMapper.    Locally-reasonable decisions have led to bad overall design, difficult entry for new cameras.   {quote}    My best guess is that this is 0.25 FTE, ongoing."
Answer: 615138.0

User story: "From [~<USER>'s [technical debt list|https://confluence.lsstcorp.org/display/~<USER>DM+Technical+Debt]:  {quote}  pex_config has no active developers, leading to a long backlog of tickets and a stall in big-picture improvements. Code is hard to read/maintain, and design is exhibiting serious limitations when used in large pipelines, especially in lack of support for ways to connect related options in different sections of the tree. Serialization with plugins continues to be fragile. Distinctions between what-to-run and how-to-run options it are not well captured, leading to incorrect provenance when the same pipeline is executed at different levels. We still haven't dropped pex_policy.  Provenance of configuration options is unnecessarily complex and developers are confused by --clobber-config behavior.  {quote}    My best guess is that this is 0.5 FTE ongoing."
Answer: 186019.0

User story: "Per [~<USER>'s request, provide Kevin with a list of milestones which we will not address in F16. Reschedule them to S16 in JIRA."
Answer: 2363.0

User story: "Add an equivalent of {{examples/runChftTest.sh}} to {{validate_drp}} to process {{validation_data_hsc}}."
Answer: 365496.0

User story: "Came across an interesting comment in {{Interp.cc}} while hunting for boost {{static_assert}} reading: {{we'd use C++11's static_assert if available}}, so decided to fix it :)  This ticket is just to track it, work was a one liner."
Answer: 5404.0

User story: "Add mock code reference roles so that authors can add semantics to their writing without attempting to make actual references to API documentation that does not _yet_ exist. Covers all roles in the Python domain, and supports tilde syntax for collapsing the namespace."
Answer: 175.0

User story: "Migrate print statements to print function."
Answer: 9718.0

User story: "* Prepare for all hands meeting.  * Present plan to developers.  * Advise developers doing migration.  * Contribute fixes as required."
Answer: 120976.0

User story: "Ensure that {{base}} works with Python 3."
Answer: 99679.0

User story: "Ensure that the {{utils}} package will work with Python 3."
Answer: 99634.0

User story: "{{sconsUtils}} has to be modified to ensure it works with Python 3. Additionally SWIG calls might need to be changed to trigger Python 3 mode."
Answer: 99202.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: "Update the developer guide to indicate that Python 3 must be supported and that code must run on Python 2.7 and 3.    This ticket will reference the tech note delivered as part of DM-6315. Writing extensive user documentation on the {{future}} package is beyond the scope of this ticket."
Answer: 146828.0

User story: "{{newinstall.sh}} currently insists on installing and checking for python 2.7. This needs to be changed to allow Python 3.    Requires {{sconsUtils}} works with Python 3 as the {{lsst}} EUPS package is installed as part of {{newinstall.sh}}."
Answer: 148606.0

User story: "Porting the stack to Python 3 is not as simple as blindly running {{futurize}}. A guide has to be written explaining the issues and providing guidance on when to accept {{futurize}} suggestions and when to ignore them. This guide will be written as a Tech Note."
Answer: 139795.0

User story: "Get {{lsstsw}} working with Python 3:  * Update the {{deploy}} script to allow a Python 3 python to be installed and modify the version checking code.  * Demonstrate that {{lsstsw}} {{rebuild}} will successfully build and install a third-party non-Scons package."
Answer: 19013.0

User story: "{{newinstall.sh}} currently installs miniconda via EUPS. To replicate that functionality in Python3 we need to create a {{miniconda3}} package. This package should be almost identical to {{miniconda2}}.    Requires that {{lsstsw}} first be updated to support python 3."
Answer: 99366.0

User story: "Modify the Scons eups package such that it can be used to build a Python 3 stack.    Originally the hope was to use a Scons that will work natively on Python 3 and 2.7 but this turned out not to be possible on the timescale required."
Answer: 99256.0

User story: "1. Update the LDM-151 draft with the SDQA Skeleton from the DMLT + SciPipelines working group discussions of May 16-20.  Implement as bullet points in a semi-coherent list. (/)    2. Clean up list. (/)"
Answer: 100.0

User story: "This ticket covers work to build a Python package/script whose role is to take JSON output from validate_drp (DM-6086), shim it into the JSON schema currently expected by the SQuaSH REST API (http://sqr-009.lsst.io), and post the data to the API's {{/jobs}} endpoint.    This tool also adds additional metadata to the ‘Job’ document, including the build ID and versions of packages as run by validate_drp (see DM-5943)."
Answer: 8524.0

User story: "Write outlines into the LDM-151 document for the alert production pipelines."
Answer: 5669.0

User story: "Everything that isn't base, utils, pex_exceptions (DM-6302), ndarray (DM-6303)."
Answer: 99216.0

User story: "Note particularly Jim's second bullet point at https://jira.lsstcorp.org/browse/RFC-182?focusedCommentId=48644&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-48644."
Answer: 80817.0