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: "{{Alloy.CFG}} is a good, safe place to put globals in your Alloy applications so that you don't need to manage a commonjs module for globals yourself. It is also where your config.json configs get stored. It would likely be more intuitive for developers if they hada clear place to store globals. For this reason, I'd like to make the {{Alloy.globals}} namespace an empty object where developers can attach globals that they can then reference throughout the application.     It seems like a little bit of overlap with {{Alloy.CFG}}, but I think {{Alloy.globals}} is far more intuitive and and much more common use case.    h4. alloy.js  {code:javascript}  // Alloy.globals by default equals {}  Alloy.globals.someGlobalFunction = function(){};   {code}    *Important*: {{Alloy.globals}} will erase the need for developers to roll their own globals libraries/namespaces."
Answer: 10263.0

User story: "See details here: https://github.com/appcelerator/alloy/pull/81"
Answer: 46437.0

User story: "TiStudio is going to rely on the results of these commands, so they need to be solid and perform as expected in all cases"
Answer: 27371.0

User story: "Need to go through the PR from aaron saunders that has improvements to the sql sync adapter    https://github.com/aaronksaunders/alloy/commit/fa92ee8f350cc0b1a9f553b806eb9628ab30df1e"
Answer: 7291.0

User story: "When there is a Alloy update detected in Studio, we would open an update dialog with release notes information (please see the screenshot in TISTUD-2441), but currently the content is hard-coded in Studio and pretty minimal. The suggestion is to have Alloy provide a change log page that will get updated each time a new version is pushed. The link could be https://github.com/appcelerator/alloy/blob/master/CHANGELOG.md, and the content could be something like the following:    {code}  0.2.43  --------   * Updated widgets, added new button-grid widget.   * Removed node-appc dependency.    0.2.42  --------    * reinvented the world  {code}  "
Answer: 1305.0

User story: For alloy projects, we need to replace the images in project's Resources folder with the ones in the attached zip before running "alloy new . <template_name>".  
Answer: 2923.0

User story: "h2. update (1/21/2013)    The {{alloy run}} command will be kep for one more minor version, but it will no longer use the old titanium.py to run. The {{alloy run}} command will literally just be routing to the new cli's {{titanium build}} command, meaning that the new cli is a dependency, but TiSDK 3.0 is a requirement for Alloy 1.0 anyway. All options and arguments will be passed directly to it. This means that:    {code}  alloy run --platform ios --sdk 3.0.0.GA  {code}    is exactly the same as    {code}  titanium build --platform ios --sdk 3.0.0.GA  {code}    h2. original    Once CLI integration is complete and Alloy has TiSDK 3.0 as a prerequisite, let's get rid of the alloy run command. It is a limited, convenience command that relies on the old build scripts. "
Answer: 146122.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 [quick start doc|http://projects.appcelerator.com/alloy/docs/Alloy-bootstrap/index.html] is a great reference for developers to get started. We need to bring it up to date a bit and perhaps hone the example to be a little less complex as a first experience with Alloy. I think a smaller, non-widget based application would be better suited for Alloy, and perhaps the existing quick start can be moved to another tab as an example of more complex alloy usage."
Answer: 133217.0

User story: "This includes all sub-commands"
Answer: 22875.0

User story: "This ticket is created to link together all other ALOY tickets that cannot be resolved until TiSDK is declared as the new minimum SDK for Alloy usage. Necessary fixes and new APIs in 3.0+ will allow us to remove a lot of workarounds and even whole modules in some cases."
Answer: 144529.0

User story: "This will speed up unit testing across all supported OSes, thus making it more likely to be run."
Answer: 18713.0

User story: Much like the the "parsers" for the compile command, we should modularize the "optimizers". Right now, the requires.js file is doing muh more than fixing require paths. We should be separating the processing into easy-to-understand chunks, since the AST parsing is confusing enough as it is.    Off the top of my head, we could break out  * defines and basic AST operations  * requires  * builtins  * widgets (check for platform)
Answer: 5463.0

User story: "The list found here will be reserved and will result in a compile error when attempted to be used in Alloy as an ID:    https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Reserved_Words    This will help enforce best practices and more readable and stable code."
Answer: 36.0

User story: "Need to send an analytics event for every alloy run like this:    {code:javascript}  Ti.Analytics.featureEvent('alloy.start', {      guid: GUID,      osname: Ti.Platform.osname,      osversion: Ti.Platform.version,      tiversion: Ti.version,      locale: Ti.Platform.locale  });  {code}    It should be placed in the alloy.js lib as this gets run at the very beginning of the generated app.js"
Answer: 2723.0

User story: "While the doc guys are kicking ass on the wiki, api docs, jsduck, etc... The github docs have fallen a bit out of sync. Also, they are a little too verbose for a format that has no table of contents. I'm going to spend a little time getting them into shape where they are actually useful to developers."
Answer: 98.0

User story: "In the run command's index.js file, we do a check to see if the given platform is mobileweb. If it is mobileweb, we exit with an error indicating the alloy run is not supported by mobileweb. This is because there's no way to launch a mobileweb app from the command line build script (pre-3.0.0), this is done solely by studio. In the future, when mobileweb does support this functionality, this error message and abort should be removed."
Answer: 93534.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: Alloy prefixes WPATH() paths with a "/" if they don't have one, since Android handles relative paths differently than iOS and Mobileweb. Once TIMOB-10783 is resolved, the workaround in Alloy can be removed.
Answer: 300903.0

User story: "Need to investigate usage a bit more to decide on exactly how this will be implemented in markup"
Answer: 19290.0

User story: {code:xml}  <DashboardView>      <DashboardItem badge="2" image="image1.png"/>      <DashboardItem badge="10" image="image2.png" selectedImage="image2_selected.png"/>      <DashboardItem canDelete="true"/>      <DashboardItem image="logo.png"/>  </DashboardView>  {code}
Answer: 25526.0

User story: "{code:xml}  <AlertDialog>      <ButtonNames>          <Name>name 1</Name>          <Name>name 2</Name>          <Name>name 3</Name>      </ButtonNames>  </AlertDialog>  {code}"
Answer: 25245.0

User story: {code:xml}  <CoverFlowView>      <Images>          <Image>image.png</Image>          <Image height="40" width="40" image="image2.png"/>      </Images>        <!-- other views to put on top go here -->  </CoverFlowView>  {code}  
Answer: 118.0

User story: "Proposed syntax:    {code:xml}  <TabbedBar>          <Labels>              <Label>tab 1</Label>              <Label>tab 1</Label>              <Label>tab 1</Label>          </Labels>            <!-- any other views you intend to overlay -->      </TabbedBar>  {code}"
Answer: 131.0

User story: "Let's organize the samples a little better, putting like content in folders. Russ already started this with the model-based test apps. Let's see if some further organization can be done."
Answer: 25.0

User story: "{{alloy.jmk}} allows a developer to add pre/post compile hooks for executing javascript code. While powerful, this is likely to very rarely be used. In the cases where it would be used, an advanced developer will have access to documentation on composing these files. Much like Titanium compiler plugins, this does not need to be present by default.     {{alloy.jmk}} functionality should remain the same in the compile command, but it should not be added to projects by default. It should be created manually (or perhaps through a generate command) by a developer when needed."
Answer: 88.0

User story: "{{JSON.parse()}} does not output the line/column at which a parsing error occurs in the data. See this thread for more details: http://code.google.com/p/v8/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Type%20Status%20Priority%20Owner%20Summary%20HW%20OS%20Area%20Stars&groupby=&sort=&id=1480    We may need to inspect nodejs modules for a better, more verbose parsing method for JSON."
Answer: 1283.0

User story: ALOY-271 covers errors from the the AST parser, but we need to step through every part of the Alloy process and make sure that all output messages are meaningful and actionable. Validation should explain what exactly failed, not just a "compile failed" message.
Answer: 1647.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: Something alone the lines of:    {code:xml}  <Alloy>      <Window>          <Menu platform="android">               <MenuItem title="option 1" icon="icon1.png" onClick="doSomething"/>              <MenuItem title="option 2" icon="icon2.png" onClick="doSomethingElse"/>              <MenuItem title="option 3" icon="icon3.png" onClick="doSomethingCompletelyDifferent"/>          </Menu>      </Window>  <Alloy>  {code}    We may even be able to eliminate the {{platform="android"}} all together.
Answer: 17590.0

User story: "This will be a reoccurring task in each sprint to keep track of how much time is actually devoted to unit testing. Details of which will be logged in each ticket."
Answer: 21956.0

User story: "h2. description    Our current parsers rely on the style being able to be parsed by the uglifyjs AST parser. Removing the commas breaks this first initial step before we pass it to the JSON parser. It shows us a larger problem in that we should probably have a complete parsing expression grammar for TSS files. This will allow us to account for more than just commas, but also comments and things like that.    We should attempt to use [pegjs|http://pegjs.majda.cz/] to create the grammar as it can then be run through Alloy's node scripts. After that it can be incorporated into Alloy, replacing the current method of using the uglifyjs AST parsing, followed by JSON.parse.     h2. notes    * We may need to drop {{expr()}} syntax to keep the grammar from needing to understand all of Javascript as well, which is not a small grammar as you might imagine. I think dropping expr() is fine as it was a catch-all before we had device queries and will be made further obsolete with the introduction of dynamic styles in ALOY-210.  * Grammar will allow us to add comments, which we can't do with the current method.  * This will make our styles more flexibile in the future if we need further changes"
Answer: 166038.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: Right now TiStudio is simply doing an "npm install alloy" to get alloy. This works for now, but eventually we are going to hit a point where non-backwards-compatible changes are made and developers should be able to manage which version of alloy they would like to install. We need to investigate from an npm perspective how different versions of Alloy can be installed, then we need to see how this can be managed inside TiStudio.
Answer: 14880.0

User story: "Due to a bug in the way Android handles PickerColumn arrays (TIMOB-10895) we need to implement a slightly less-than-optimal way of adding picker columns to pickers. Instead of composing an array of PickerColumns and then adding the array to the Picker, we need to add each PickerColumn individually to the Picker.     Not a big deal, just requires a less-than-optimal solution til this is fixed.    "
Answer: 997016.0

User story: "With a need for source mapping and other features that may not be readily available for us in uglifyjs, and the desire to use less external technologies, we should consider the code-processor project for our AST parsing, compiler conditionals, etc... for Alloy.    Will need to have discussion with Bryan to see if code-processor covers our necessary list of features, and if it will making true debugging of alloy apps, in alloy code, easier than if we tried to do it with uglifyjs v2."
Answer: 90988.0

User story: We need to determine exactly how the Titanium CLI will impact Alloy.    * Will it support the existing compiler plugins or will new ones have to be written? Will we have to support 2 different plugins in order to be compatible back to 2.1?  * How will this impact the "run" command and the common/titanium.js implementation?  * Talk with Chris barber to determine if there are any other critical things we need to be aware of.
Answer: 47786.0

User story: "* test all existing integrated functionality  * further evaluate the output enhancements from sprint 19  * see if there are any other critical integration points we should get before codestrong    All work derived from this ticket will get tickets of their own."
Answer: 27757.0

User story: "Let's assess the current state of Alloy's documentation:    * Do we have good coverage from the docs provided by the docs team?  * If not, where do we need improvement?  * Should the quick start be updated with more samples? Perhaps separate tabs sections for high level Alloy concepts like view/controller creation, using models, etc...  * Do we need to consider wiki/training docs?    Any work resulting from this ticket will be put into a ticket of its own."
Answer: 22579.0

User story: "We have pretty sold coverage of the Ti APIs in terms of markup parsers. Let's dig into the API a bit more to make sure we're not missing any common cases that would require special tag parsers.    Any parsers that need to be created as a result of this analysis will get their own tickets."
Answer: 38276.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: "Since true debugging will need to wait a bit, let's see if we can improve the output from uglifyjs to make it a bit more readable."
Answer: 22229.0

User story: "While this seems like a simple task, our current parsers rely on the style being able to be parsed by the uglifyjs AST parser. Removing the commas breaks this first initial step before we pass it to the JSON parser. It shows us a larger problem in that we should probably have a complete parsing expression grammar for TSS files. This will allow us to account for more than just commas, but also comments and things like that."
Answer: 170349.0

User story: It seems as though XML formatting errors are being reported in the log, but not aborting the Alloy build process. For example:    {code:xml}  <Alloy>   <Window32 id="index">    <Button id="b" class="button" onClick="showAlert">Hello, World!</Button>   </Window>  </Alloy>  {code}    This causes the following error message to appear in the log:    {code}  end tag name: Window is not match the current start tagName:Window32  {code}    But it does not abort the build until a later error forces it to. These XML errors should be caught when they occur and conveyed to the developer so that they can fix them before the app runs, not simply warn them and have them encounter unexpected behavior.
Answer: 2947.0

User story: "We need to discuss the potential usage of form factor specific alloy files. Before considering its implementation, we need to establish clear use cases for this that can't be achieved through use of styles, device queries, and the {{formFactor}} XML attribute."
Answer: 80889.0

User story: "Alloy developers to specify platform-specific alloy files, like views, controllers, and styles. The platform-specific files will be located in directories within the alloy structure. For example, a ios-specific view and an android-specific controller would be done like this:    * app  ** controllers  *** android  **** index.js  *** index.js  ** views  *** ios  **** index.xml  *** index.xml    Alloy will use compile-time knowledge of the build to determine which files will be used."
Answer: 8713.0

User story: "We should create a default .gitignore, or update the existing one, for alloy projects. It should include:    * .DS_Store  * build.log  * Resources    This issue is dependent on a yet-to-be-created TiStudio ticket for handling projects with no Resources directory."
Answer: 881667.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: h2. description    Implement all versions of the Ti.UI.Picker. Original request for this functionality can be found here: https://groups.google.com/forum/?fromgroups=#!topic/appc-ti-alloy/OS3XZrpwp1Q    h2. Proposed snippet    h4. Single Column  {code:xml}  <Picker>      <PickerRow title="0"/>      <PickerRow title="1"/>      <PickerRow title="2"/>      <PickerRow title="3"/>  </Picker>  {code}    h4. Multi-Column  {code:xml}  <Picker>      <PickerColumn>          <PickerRow title="0"/>          <PickerRow title="1"/>          <PickerRow title="2"/>          <PickerRow title="3"/>      </PickerColumn>      <PickerColumn>          <PickerRow title="0"/>          <PickerRow title="1"/>          <PickerRow title="2"/>          <PickerRow title="3"/>      </PickerColumn>      <PickerColumn>          <PickerRow title="0"/>          <PickerRow title="1"/>          <PickerRow title="2"/>          <PickerRow title="3"/>      </PickerColumn>  </Picker>  {code}    h2. Notes    * Let's create shorthand names that the parser can identify to make it even easier?  ** {{PickerColumn}} -> {{Column}}  ** {{PickerRow}} -> {{Row}}  {code:xml}  <Picker>      <Column>          <Row title="0"/>          <Row title="1"/>          <Row title="2"/>          <Row title="3"/>      </Column>  </Picker>  {code}
Answer: 19052.0

User story: "The quick start is at: http://projects.appcelerator.com/alloy/docs/Alloy-bootstrap/index.html    It should likely exist somewhere officially on the docs.appcelerator.com site."
Answer: 192801.0

User story: "Details on why this workaround exists can be found here: https://jira.appcelerator.org/browse/ALOY-224"
Answer: 210459.0

User story: In the {{processIf()}} function of the {{Alloy/commands/compile/optimizer.js}} file, there is a section where it attempts to determine how to process an "if" statement if it is checking for iPhone, iPad, or Universal. At compile time currently, though, there is no distinction between ipad and iphone when a universal build is selected.     We need to investigate to see if there is a way to make this distinction, and if there is, move these checks to compile time. It's also worth noting that we might want to wait on this one until the new CLI is created: TIMOB-8652
Answer: 160518.0

User story: "Currently the column names for a SQL migration go through normalization at runtime in the sql.js sync adapter in the {{SQLiteMigrateDB()}} function. We should find a way to do this normalization at compile time to improve performance."
Answer: 627513.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 {{subprocess.check_output}} method is currently used by the ti.alloy compiler plugin to execute the appropriate commands and output error information, if necessary. While this works well and gives us good error logs, it only works for python 2.7+, where in its current state, Titanium supports 2.6+. There is a fallback function that is executed in case the developer does not have 2.7+ installed, {{}}. This method, unfortunately, does not give the full error log {{subprocess.check_output}} does.    We need to implement a method in the ti.alloy compiler plugin that allows for solid error output on python 2.6+. "
Answer: 39440.0

User story: We need to determine how we would like to manage the custom changes made to uglifyjs to make it work for alloy. Specifically, a couple of (minimal) changes were needed to facilitate our JSON-derivative tss file format. As it stands now, these changes are simply noted with TODOs in the uglifyjs source code that is part of the alloy project.     For the time being, this is OK. if we ever need to update uglifyjs or track our own changes, it becomes a little more difficult to handle. There's a couple ways we can proceed.    # Continue to use a specifically marked TODO, perhaps that references this ticket, and re-insert the changes into any new version of uglifyjs. Not ideal, but we may never need to update uglifyjs and this would be the minimum amount of work.  # Keep an open ticket or wiki document that keeps track of the uglifyjs changes, just so we have a reference outside of the code itself. Not sure this is entirely necessary or gets us much.  # Fork uglifyjs. Make the custom changes in our fork and update from the upstream uglifyjs if necessary. This would be the "best" way to do it, but is likely more work than we should worry about now because as stated before, we may never even need to update uglifyjs    I'm leaning towards #1 for the time being. We can revisit later if we find updating uglifyjs is a reoccurring event. Thoughts?
Answer: 61488.0

User story: "Right now, if no specific platform is given to the {{Alloy/common/titanium.py}} {{run()}} function, {{iphone}} is assumed. It would be better for alloy to investigate the project's tiapp.xml file and determine which deploy-targets are enabled, as 'iphone' may not even be enabled for the current project."
Answer: 54025.0

User story: "Right now parser output is vague. It only lets you know the name of the element that failed and the rule that it broke. You can kind of determine what file caused it by other non-related log output, but it would be better to improve it.     To do so, we should pass some additional information into the parser via its {{state}} variable. We could pass in things like view name, view file path, potentially its position in the XML/file, etc...    This will greatly improve the debugging experience. The change itself will not be huge, but it will require a great deal of testing to ensure that we get good output."
Answer: 24588.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: Inspect {{<Require>}} elements under a {{<View ns="Ti.Map">}} and make sure that it in fact contains a single annotation during the annotation processing phase of the Ti.Map.View.js parser. 
Answer: 1491.0

User story: "As it stands now, all requires for Alloy.Require (<Require>) nodes is performed at runtime. These nodes simply create a {{require()}} statement that will create a controller for use at runtime. By checking in the Alloy.Require.js parser itself for the file path, though, we can actually confirm at compile time if the required file exists or not, saving developers (or worse, their end users) the time and aggravation of figuring this out at runtime.  "
Answer: 23357.0

User story: "We need to determine the minimum version of the TiSDK that Alloy will support. In light of tickets like the following:    * ALOY-209  * ALOY-210    it would be beneficial for the alloy team if only 2.2 (3.0) or higher was supported. We need to confirm that a decision like this is in line with the company expectations of how Alloy will be delivered and what it should support."
Answer: 3253.0

User story: "h2. update    The ti.physicalSizeCategory is being removed from Alloy for version 1.0.0. Its usage will be replaced by the Ti.Platform.Android.physicalSizeCategory API present in TiSDK 3.0+. Developers have probably never used the module directly, as it was just there to support the Alloy.isTablet and Alloy.isHandheld functions.    h2. original    The ti.physicalSizeCategory module is necessary to allow us to handle device queries based on device size on Android. As of this [pull request|https://github.com/appcelerator/titanium_mobile/pull/2610], this functionality has been integrated into titanium_mobile. The first version to have this change available, though, will be 2.2.0 (3.0). We have a couple options:    # We could leave it how it is and have ti.physicalSizeCategory added to all apps  # We could inspect the build details of each app and only add the module for Android apps lower than 2.2 (3.0)  # Alloy could only support 2.2.0 (3.0) or higher    Obviously #3 would be the easiest, and may also be necessary for ALOY-210"
Answer: 211132.0

User story: "Apps are localized via the {{i18n}} directory: https://wiki.appcelerator.org/display/guidesSnapshot25Oct2011v2/Internationalizing+your+Application    We need to determine how we will handle this in alloy. Possibilities:    # Just drop it in the {{assets}} and/or {{lib}} directory. Confusing, but will work.  # Put it in the top-level app directory like this: {{/app/i18n}}    I like option #2 personally as I think having localization visible at the top-level is a good thing. It makes it clear to the developer to expect that localization will be present in the project."
Answer: 1283.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 need much more helpful command line help. We list the valid commands and options, but we don't list them in any detail whatsoever, nor do we have examples. In addition, we should probably consider a syntax where you can do a generic {{alloy help}} call, or a help call that is specific to each command, like this: {{alloy help compile}}. The command-specific help could function just like it does for {{git}}."
Answer: 54145.0

User story: "Right now the available commands are hard-coded in {{Alloy/alloy.js}}. We should instead create the array of valid commands from the directory names listed in {{Alloy/commands}} and confirm that they have an {{index.js}} file in them.    https://github.com/appcelerator/alloy/blob/master/Alloy/alloy.js#L18-19"
Answer: 33427.0

User story: "There's TODOs littered throughout the alloy code. We need to find and log all of them. The TODO comments should be modified to include the ticket number created for it."
Answer: 399.0

User story: "Follows very closely the format of ALOY-187"
Answer: 5888.0

User story: To build the Alloy docs using JSDuck, we need to comment the classes that should be exposed, and remove any comments that look like doc comments--that is if we do this:    {code}  /**   * Do something here.   */   exports._ = function() ...  {code}    JSDuck will add a global method called "_" with the description "Do something here." Changing the doc comment intro {{/\*\*}} into a regular comment intro {{/\*}} eliminates the rogue method.    Currently, it looks like we should be building docs from Alloy/builtins and Alloy/lib.  
Answer: 6986.0

User story: "Create a workflow for the analysis, acceptance, and merging of external developer submitted pull requests."
Answer: 1.0

User story: "h2. Update    I spoke with the author of the PR, [killix|https://github.com/killix], and he noted that if PR #55 was resolved, the past 3 tickets mentioned in this ticket could be closed as they were part of #55. #55 is a massive PR, though, spanning about 900 lines of code and 11 different files. We will need to discuss the changes, make sure they are in line with Alloy's design, test them against our test apps, document any changes visible to developers, and communicate these changes.        h2. Original ticket description (old)    The following PRs regarding the sql sync adapter and the sql_model sample need to be addressed via the [pull request workflow|https://wiki.appcelerator.org/display/pe/Pull+Request+Workflow] and merged, if they are accepted based on the workflow assessment.  * [PR #43|https://github.com/appcelerator/alloy/pull/43]  * [PR #44|https://github.com/appcelerator/alloy/pull/44]  * [PR #49|https://github.com/appcelerator/alloy/pull/49]"
Answer: 44192.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: h2. update    The "models/todo" test app will likely be used as the app by which sync adapters should be verified.    h2. original ticket    Instead of having separate test apps for all of our model adapter:  * sql  * properties  * localStorage    we should probably have a single validation app that confirms that the adapter fundamentally works. A good candidate would be the app that currently validates the properties adapter, as it makes use of single models, models in collections, and user interactivity that creates, deletes, and modifies models and collections. That sample can be found here:    https://github.com/appcelerator/alloy/tree/master/test/apps/properties_model    This will allow us to assert that our existing adapters, and any future adapters, perform all of the core functionality that is necessary of all adapters. We can still have separate apps for each adapter if we feel it is necessary to show off adapter-specific functionality, like queries in SQL for example. Right now, though, none of our current adapter test apps show any adapter-specific functionality and are thus not necessary if all adapters run as the current properties_model app does.
Answer: 202012.0

User story: "The linked ticket indicates that module ids in TiStudio don't handle casing properly, which impacts our module checks. See TISTUD-2114 for more details."
Answer: 236271.0

User story: "move config.json to root and get rid of alloy.json"
Answer: 3420.0

User story:  After having a lengthy discussion with Tony and Rick we may want to support both an Inculde and a Require element as the two elements provide quite disparate featues. Rick or Tony feel free to expand if you think I missed something.    index.xml  <Window id="win1">    <Include src="myMarkup"/>   </Window>    Would take the markup that is in myMarkup.xml and make that markup avaialable as it is under it's parent element "win1". This is good for quick reuse of fragments of markup (XML). If say within myMarkup.xml you had a Button say with id "btn1" then within the index.js controller the Ti.UI.Button proxy is accessed through "btn1". There is no associated style     On the other hand    index.xml  <Window id="win1">    <Require src="myView" id="view1"/>   </Window>      Would take the controller (trifecto) and add that to the index.js controller. Styles and the source controller myView.js of myView is maintained. It's like a var view1 = require("myView").create() being done automatically for you and the view hierarchy still under "win1". If myView had a Button with id "btn1" In index.js controller the developer would access the button through "view1.btn1". The advantage here is trifecto reuse and never any id collisions. If the name attribute is missing we can use the view name.         From Rick B      Include:  https://gist.github.com/3219597    Require:  https://gist.github.com/3219595    h4. other suggestions    {code:xml}  <!-- for widgets -->  <Require widgetId="widgetId"/>  {code}  
Answer: 11393.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: "Make sure children of Alloy are SplitWindow, Window, TabGroup only. On others stop parse and report error."
Answer: 733.0

User story: "I think this means we can get rid of the $. syntax completely."
Answer: 19323.0

User story: "The sample app can:  * show list of products  * info for each product  * videos and fotos for each  * zoom in/out of the images  "
Answer: 99813.0

User story: "Models are currently only processed from the main {{app/models}} directory, not from within widgets. Widget models need to be processed, encapsulated, and made available at runtime via modules, just like with views."
Answer: 304892.0

User story: "h2. Steps:    * Identify all functions via uglify AST  * find add() and remove() functions  * insert runtime check to see if the first parameter is an alloy component (can't determine at compile time in all cases)  * if it is, append {{.getRoot()}}    A converted chunk of code will look something like this:    h4. before  {code:javascript}  var win = Ti.UI.createWindow();  win.add(Alloy.getView('someview').create()); // this will fail  {code}    h4. after  {code:javascript}  var win = Ti.UI.createWindow();    // need to use an anonymous function as the argument could be a function   // and we don't want to execute it more than once   win.add((function(t) {      return (_.isObject(t) && t.__iamalloy__ ? t.getRoot() : t) || t;  })(Alloy.getView('someview').create()));  {code}    h2. caveats    * Checks need to be made at runtime, otherwise there's no way to know if the evaluated object is actually a component. Same goes for whether or not the calling object is a Ti proxy.  * Will only work for {{add()}} and {{remove()}}. Other Titanium view hierarchy methods are not yet supported, like {{open()}}, or adding tabs to tabgroups, or rows to tables. Assembling the full list at the Alloy level to achieve consistent behavior could be tricky.  In fact, I don't think it would be possible at the Alloy level to handle table rows since most often they are added via an array to {{setData()}}. Hopefully this can be alleviated in the future by table row template/model binding.  * Still need to figure out a way to reliably determine if the caller is a Titanium proxy. Without this there are bound to be false positives. [TIMOB-5744|https://jira.appcelerator.org/browse/TIMOB-5744] prevents reliably using {{toString()}} comparisons. Perhaps I can check for specific properties or functions on the object."
Answer: 48205.0

User story: "From email conversation with <USER>    Let's make it the next priority then to really come up with a really really slick and simple set of webpages that walk people through the basics of alloy.    we should come up with something like this (with this level of standard ... in fact, maybe just use bootstrap itself).    http://twitter.github.com/bootstrap/    Something very simple and very visual for the developer."
Answer: 20780.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: "Allow developers to specify a global style that applies to all components. This global style will hold an identical priority value to that of each component-specific style, but will be processed before the component-specific style. This means that all ties in terms of priority will go to the component-specific style.    I am going to name this style {{app.tss}} and put it in the normal {{styles}} folder. If some has a better idea for its name (I kicked around {{alloy.tss}}) let me know."
Answer: 424.0

User story: "Either create separate release notes or add the following in the current readme    * installation requirements, ie environments, dependencies   * list of known issues"
Answer: 58851.0

User story: "Incorporate a Titanium-compatible REST adapter into Alloy. The open source REST adapte written by <USER>would be a good start.    https://github.com/<USER>napp.alloy.adapter.restapi"
Answer: 686575.0

User story: "We have Jasmine support available but Anvil is the new engineering standard not just for internal engineering but also for external developers, so Alloy we will need to support it.    Anvil overview: https://wiki.appcelerator.org/display/spe/Anvil+testing+framework+overview    This ticket will cover only the scope of establishing whether or not Anvil works for Alloy's internal testing and creating a basic, initial unit test. This will serve as a sample for future issues that will detail specific areas of testing."
Answer: 402512.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: h4. view prototype  {code:xml}  <Collection src="myCollection"/>    <TableView dataCollection="myCollection" dataTransform="transformProperties" dataFilter="filterCollection">    <TableViewRow title="{title}"/>  </TableView>  {code}    h4. controller prototype  {code:javascript}  // "model" refers to the current model being rendered from the collection. This transformation  // function should return a Javascript object containing properties that you want to   // modify and use in the binding. So for example, if we wanted to wrap the title from the model  // in square brackets we could do the following:  function transformProperties(model) {      // Get the JSON object representing the current model's attributes      var transform = model.toJSON();        // Make the aforementioned modification      transform.title = '[' + transform.title + ']';             // return the transformations, no changes will actually be made to the model      return transform;  }    // "collection" is the collection being used as the data source for the tableview. From this  // function we can return an array that is either the full set of models from the collection,  // or a filtered subset. The returned  function filterCollection(collection) {      return someConditionalFunction() ?           // return the full set of models from the collection          collection.models :            // render only models with "someString" in the title          collection.where({ title: title.indexOf('someString') !== -1 });   }  {code}    * - *dataCollection* will refer to an instance of a collection containing models that you would like to be iterated over in the associated view, in this case a TableView  * - *dataTransform* will refer to a function defined in the associated controller that will allow you to modify each model before rendering it in the "repeater". This will most commonly be for transformation and normalization of data.  * - *dataFilter* will refer to a function defined in the associated controller that will allow the developer to filter down the list of models from the collection that should be rendered as rows.   * - Both *dataTransform* and *dataFilter* are optional.  * - Bound properties from the models can be accessed using the *\{\}* notation, where the property refers to a property on the model.  * - The TableView should be able to render inline rows, as well as <Require> rows as well.  * - When bindings are used in a separate controller, like if your TableViewRow definition is in its own controller, the current model can be references with the *$model* variable in the controller code.  
Answer: 174760.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're working on model-view binding on controls like tableviews that rely on a collection, but it would be good to also allow single components to bind to a single model. In this way, changes to the state of a model can make changes to singular components like Labels, TextFields, Buttons, etc...    raw protoype  {code:lang=xml}  <Model src="myModel"/>    <Label text="{myModel.text}"/>  <TextField value="{myModel.someValue}"/>  {code}
Answer: 223946.0

User story: "In Ti Studio it would be awesome to set breakpoints in source code (xml, controllers) to aid in creating applications. Investigation should look at creating a source map during the Uglifyjs AST process and the Alloy xml parse process. Once the source map is created how will we hook into Ti Studio/Eclipse debugger system. This task should have subtasks that further break down and scope this task."
Answer: 152601.0

User story: The descriptor should be the same as widgets. For example,    {   "id": "com.appcelerator.sample.acs",   "name": "",   "description" : "ACS Demonstration Sample",   "author": "",   "version": "1.0",   "copyright":"Copyright (c) 2012 by Appcelerator",   "license":"Public Domain",   "min-alloy-version": "0.1.16",   "min-titanium-version":"2.0",   "tags":"acs,cloud,login,custom objects",   "platforms":"android,ios,mobileweb"  }
Answer: 23921.0

User story: "These templates are runnable but are do nothing apps but are the building blocks for more complete apps."
Answer: 9531.0

User story: "Does it make sense to have those under the test folder?"
Answer: 9534.0

User story: "The tags section will be used by Ti Studio to display widgets matching descriptor"
Answer: 9547.0

User story: "There is currently an ACS adapter in the community written by Aaron Saunders. I will work with Aaron to see if we can get it incorporated into the core of Alloy."
Answer: 796483.0

User story: "Need to have Dawson review Alloy version of his app and create tickets for all items that Dawson feels need to be included in Alloy to be useful for developers."
Answer: 12759.0

User story: "In order to leverage some of Titanium Studio's features, and OS features, we are going to rename the views extensions to {{txml}} and the style extensions to {{tss}}. These first need to be abstracted out into constants and then changed in the appropriate places in code. While the models and configs will continue to use the {{json}} extension, they will also be abstracted out to constants in case they change in the future."
Answer: 4407.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: Jira ticket for adding a bulk style setter and getter - we should watch this and if it appears performance is bad with setting individual styles we may need to up this tickets priority.      We want to be able to specify styles specific to the current platform and/or form factor, much like media queries on the web. To do so, we have 2 options    # use separate files sporting a specific convention to identify platform and/or form factor  # use "selectors" of some kind in the style files themselves    These methods are detailed in the sub-tasks related to this issue
Answer: 10525.0

User story: "Widgets will need dependency management if we are to build widgets composed of other widgets that may or may not already be in a project. Some things we'll need to do so:    * A {{dependencies}} key in the manifest. We should probably format this just like the dependencies in nodejs packages to keep it familiar and flexible.   * A dependency manager that needs to be able to:  ** check if dependencies are met for a project  ** make supported widgets available for installation (think {{npm install PACKAGE}})  ** add publicly available dependencies to project when needed, just as npm would.    These bullet point will probably require integration with TiStudio. The logic of the dependency manager probably makes most sense in a compiler plugin right now, but this may change as the CLI changes."
Answer: 1921655.0

User story: "We need to provide jsduck compatible documentation for builtins and then work with doc team to get them integrated (along with generic Alloy doc) with docs.appcelerator.com site."
Answer: 89798.0

User story: We will need to probably build out a system by which we can do various combinations of XML from View markup.    For example, in Ti, we have certain parent/child relationships to certain objects which need to be mapped so that its more helpful in XML.      Example is a map.  Ideally, you would do something like:    {code:xml}  <map>    <annotation></annotation>  </map>  {code}    As a way to statically build a map with a single annotation.    Also, in the tableview, you have a similar scenario but with additional nesting possibilities:    {code:xml}  <tableview>    <tableviewrow>      <imageview url="foo.png" />    </tableviewrow>  </tableview>  {code}    Also, as in the map above, we need to also be smart about Ti builtins to make sure we auto-prefix the ns (Ti.Map vs. Ti.UI) in these cases.  
Answer: 31690.0

User story: "Need to make sure alloy works on all of Titanium's supported platforms    * windows  * mac osx  * linux    All basic commands and operations should be verified on these platforms. Additional code will likely be necessary to support Linux and Windows, particularly Windows."
Answer: 205152.0

User story: 1) Build the ZipTi project, it could be a starter "hello world" app.  2) Run translator to generate app.js, css, and any support files.
Answer: 202893.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: "A popular class of applications starting to show up on mobile devices is the brochure app. They are apps that gives you a virtual and interactive overview of a product. Having a template that creates the scaffolding and then a complete app that has art, effects and flow would be a good start to quickly building one of these apps. For example,     http://www.motorauthority.com/news/1073083_mercedes-benz-launches-c-class-brochure-app    Clothing, Autos, Kitchen Appliances could be good start points for one of these apps."
Answer: 150138.0

User story: "1) Restaurant App that includes menu and location. Includes a Node.js proxy for mobile web RSS. RSS part should come from Tim's training/tutorial  2) TBD  "
Answer: 202953.0

User story: "This story relies on first defining and creating the widget api.       1) Infinite TableView widget. Buffer rows. PS uses a lot but there is not yet a reusable design pattern  2) Cross platform per iOS & Android HIG navigation bar  3) ACS Login  4) Info button  5) Combo box"
Answer: 202963.0

User story: "Since Node.js is the preferred translator runner it would be ideal to package up the translator as a NPM package."
Answer: 105109.0

User story: "A template and sample that creates a cloud based ToDo list. The app should put up a nice login widget and once logged in show a table view of the items in my list. The user should be able to check off items in the list and remove and add items as needed.    Please see the attached files as examples."
Answer: 150127.0

User story: "h2. Description    ZipTi needs to have comprehensive logging. This includes logging during translation as well as runtime logging to account for the difficulty in debugging DOM generated code. We need to try to eliminate the inevitable developer pain points that come from an additional layer of abstraction.    h2. Runtime    use Ti.API functions for logging to the console. We should probably have a way to control the verbosity of the output.    h2. Translation    Use console.log() from node for output.   "
Answer: 104976.0

User story: Hi,   i can not use python plugin (pydev) because of this error that happen in code completion :    "Port not bound (found port -1). Is there an enabled    firewall?"
Answer: 334941.0

User story: "h3. Steps to Reproduce Just because I type an apostrape does not mean Inned 2 at that particular moment. It is really causing me problems. All steps to disable this that I have found on the interent have been useless.  h3. Actual Result I get 2 apostraphes instead of one. I really do not need autocomplete.  h3. Expected Result Disable this 'feature'."
Answer: 1381.0