Hello everyone, Nice hearing you all again. I would be for option C. I think it is important to have 2 presentations, for motivation and other already mentioned. But it could be a little bit shorter, I remember it was my first presentation (outside faculty) and I was very nervous.
All the best, Jelena Skorucak On Thu, Apr 5, 2012 at 10:38 PM, Michael Seaton <[email protected]> wrote: > ** > What about the option of moving these into the university call slot 2 > times / month during the summer? > > > On 04/05/2012 04:22 PM, Burke Mamlin wrote: > > I prefer option D – i.e., returning to the time/format we had before for > these calls. I have a conflict the hour before the current Dev calls, so > wouldn't be able to enjoy half of the presentations if the call started > earlier. > > -Burke > > On Thu, Apr 5, 2012 at 1:47 PM, Michael Downey <[email protected]>wrote: > >> Hi developers, >> >> As you know, last year we had each of our Google Summer of Code >> students present their work twice for 15-minutes each time during the >> program. Since then, we have shortened the duration of our weekly >> developer forum to one hour, so we need to re-think the arrangements >> for this year. >> >> I'd like to open a dialogue for the next week or two to get your >> feedback about how to proceed. Please reply to this thread and let us >> know which of the following options you agree most with. >> >> A: The presentations aren't very useful and we should not do them this >> year. >> B: We should keep the 15-minute presentations but have the students >> present only once during the summer. >> C: We should shorten the presentations significantly but still have >> the students present twice during the summer. >> D: We should keep the 15-minute presentations twice during the summer, >> and extend the meeting an extra hour LATER when the presentations >> happen (2 times per month). >> E: We should keep the 15-minute presentations twice during the summer, >> and start the meeting an extra hour EARLIER when the presentations >> happen (2 times per month). >> >> If you think of alternative approaches not mentioned above, feel free >> to suggest them. >> >> Thanks for your feedback! >> Michael >> >> _________________________________________ >> >> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to >> [email protected] with "SIGNOFF openmrs-devel-l" in the body >> (not the subject) of your e-mail. >> >> [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l] >> >> > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
