https://devsummit.aspirationtech.org/index.php?title=Why_Code_Sprints%3F_And_How%3F&feed=atom&action=historyWhy Code Sprints? And How? - Revision history2024-03-28T10:34:16ZRevision history for this page on the wikiMediaWiki 1.35.1https://devsummit.aspirationtech.org/index.php?title=Why_Code_Sprints%3F_And_How%3F&diff=425&oldid=prevVivian: 1 revision imported2015-05-05T18:07:47Z<p>1 revision imported</p>
<p><b>New page</b></p><div><br />
<br />
=== self intros ===<br />
General topics:<br />
* How are people using hackathons<br />
* How to bring in people (non-coders)<br />
* sustainability.<br />
<br />
===What is the win? ===<br />
Maybe not the code produced. Everyone agrees sprints are good, but it is hard to put finger on specific results. <br />
<br />
* sand drawings / mandelas made by Tibetan monks get destroyed after use<br />
<br />
* pizza oven sprint, masons get together and* build an oven.<br />
wins:<br />
* design of pizza ovens<br />
* practice of building. <br />
<br />
<br />
<br />
What is sustainability?<br />
* does the code get supported <br />
* does the code get reviewed / commited. <br />
<br />
===What is a hackathon ? ===<br />
Getting people together for a short amount of time 3 to 24 hours who care about something to work on goals <br />
<br />
example: DrupelCon codepsrint after every 'Con, issues are identified people go to room to classes of <br />
<br />
Drupal Media Module code sprint was committers only for 5 days. <br />
<br />
Commonality, is bringing together people ordinarily not physically together. <br />
===Examples: code sprints===<br />
<br />
Mapping parties. <br />
<br />
===Pros===<br />
* Access to core contributors. <br />
* getting people in same room to improve <br />
* easy entry for new people <br />
** limited commitmen<br />
<br />
<br />
* get a lot of work done in short amount of time (debtable: )<br />
* Energy --requires building on ongoing<br />
* build community<br />
* somebody reading your code 10 minutes later<br />
* face to face contact<br />
<br />
===Cons (caveats?) ===<br />
* civic hackathons by boston city to design apps build apps for selves<br />
** pub crawl app won. <br />
* need to have people in room who aren't developers or designers but users<br />
* focus is hard to come by <br />
** walking in with a goal is needed but rare<br />
* need incentives to focus <br />
** money in contest incentive<br />
* sustainability is huge <br />
* be clear on goals: sort ideas ? sort solutions ?<br />
* proof of concept good.<br />
* contest <br />
* '''goals''' important<br />
* What are you going to do with half finished thing. <br />
* don't think about getting a product. <br />
* tough to get city staff involved on saturday<br />
<br />
===future code sprint ideas===<br />
* define problems<br />
<br />
===Important things for good sprints ===<br />
* organize , have things for people to do<br />
** easier with established projects with issue queues<br />
* get in designers not coders<br />
** designers won't sit behind screen for 18 hours<br />
* think about setup to attract diversity of people<br />
<br />
<br />
===definitions===<br />
Contests vs adding to code base<br />
hackathons where developers<br />
more built around publicity than results. <br />
Here's an event we're great<br />
Getting users & coders together winds up as design sprint<br />
24 sprint for web site development<br />
<br />
===Layers maodule ===<br />
Took code in sub optional<br />
<br />
===Contest hackathons ===<br />
* when city has contest doesn't create product because it doesn't fit RFP<br />
<br />
===related issues==<br />
app contests that offer $1000 for a year's work.<br />
<br />
===TS people ===<br />
Still inclined to do a sprint but manage expectations, focus on RFP</div>Vivian