mbernst
commented
10 years ago @ato1120 might have ideas
Open mbernst opened 10 years ago
mbernst
commented
10 years ago @ato1120 might have ideas
negarrahmati
commented
10 years ago Just brainstorming here...
I think we need to be able to add/remove members and events while the team is running. We might need the pause button to be able to add/remove events after the team has started running.
We could also ask users to estimate their task's run time after they have started doing them and draw the task again if their estimation varied a lot with the initial estimation of the task's run time. I am suggesting this because I assume delayed tasks and all the emails that are sent out might stress out the users.
I think pipelining is feasible with the collaborations. But, as far as I know, when a task is delayed or completed early every remaining task is shifted in time. This should happen only for the related tasks.
Negar
On Mon, Mar 24, 2014 at 10:33 PM, Michael Bernstein < notifications@github.com> wrote:
@ato1120 https://github.com/ato1120 might have ideas
Reply to this email directly or view it on GitHubhttps://github.com/StanfordHCI/flash-startups/issues/80#issuecomment-38532279 .
dretelny
commented
10 years ago I agree with Negar!
For elasticity to occur via Foundry, we need to add/remove members and events while the team is running. I brought this up in one of our earlier meetings but we decided to not deal with this feature right now. Pipelining happens via collaborations and handoffs. We will need to discuss whether we should test different types of workflows/pipelines like we did in the previous studies (i.e. sequential, interdependent, etc.)
Daniela Retelny Stanford University Department of Management Science and Engineering (914) 450-2033 dretelny@stanford.edu www.danielaretelny.com
On Mar 25, 2014, at 5:13 PM, Negar notifications@github.com wrote:
Just brainstorming here...
I think we need to be able to add/remove members and events while the team is running. We might need the pause button to be able to add/remove events after the team has started running.
We could also ask users to estimate their task's run time after they have started doing them and draw the task again if their estimation varied a lot with the initial estimation of the task's run time. I am suggesting this because I assume delayed tasks and all the emails that are sent out might stress out the users.
I think pipelining is feasible with the collaborations. But, as far as I know, when a task is delayed or completed early every remaining task is shifted in time. This should happen only for the related tasks.
Negar
On Mon, Mar 24, 2014 at 10:33 PM, Michael Bernstein < notifications@github.com> wrote:
@ato1120 https://github.com/ato1120 might have ideas
Reply to this email directly or view it on GitHubhttps://github.com/StanfordHCI/flash-startups/issues/80#issuecomment-38532279 .
— Reply to this email directly or view it on GitHub.
Our paper will presumably be talking about elasticity and pipelining. But if that's not possible or representable in Foundry, reviewers might get confused. How should this work in Foundry, and the runtime, for the UIST paper?