(C) 2011 — Software Languages Team, University of Koblenz-Landau
Navigation
Submission deadline
June 17, 2011 (End Of Day, Koblenz timezone)
Assignment
Read all of this assignment before you start writing or asking.
Have a *deep* look at the proposal template (on the non-public wiki) before you start writing or asking.
Finally, create a proposal site (on the non-public wiki).
Logistics
Each student must create an individual proposal.
(The issue of team assembly will be addressed later.)
An acceptable proposal is required, if you want to qualify for the exam.
This is a binary system: your HIWI decides whether or not your proposal is acceptable.
Your proposal may be conditionally accepted subject to a revision by you according to requests by your HIWI.
(If you plagiarize existing proposals, your proposal will not count.)
The proposal must be added as a site to the 101hackathon wiki.
In addition, you must notify your HIWI of your site's URL by the deadline.
(Always mention "101hackathon" in the subject line of any email that is concerned with this Hackathon.)
Guidance
Have a look at the template proposal (on the non-public wiki) to understand the format.
(Your proposal can start as a copy of the template with a new, unique name with "proposal:" prefix.)
Have a look at the list of proposals (on the non-public wiki) to inspire you.
(You should append your proposal, once it is ready and submitted, to this list so that it is discoverable for others.)
All proposals must target the 101companies Project.
Proposals can target contributions of the following kind:
Most likely, your proposal will focus on implementations of the 101companies System:
- Revise an existing implementation to resolve an "interesting" issue.
- Revise a small set of implementations for clarity and consistency.
- Contribute a new implementation with an "original" motivation, e.g.:
- Explore a language with "original" language concepts.
- Explore a a technology with "original" capabilities or qualities.
Do not propose new features for the 101companies System. Obey the existing feature model. In particular, do not propose new kinds of functionality (such as cut or total). The reason for this constraint is that new operation lead to feature creep and make the implementations less comparable. Of course, you can deal with interesting variations on existing features (such as cutting all managers, only). If you are confident that a new feature would be needed, then please contact softlang through email or discuss your ideas on twitter @progkob first.
You may also come up with entirely different kinds of proposals that are focused less on specific implementations, that are focused instead on documentation and infrastructure. Such proposals are likely to require more creative thinking, but they do not need to imply more work. Two generic examples are provided to inspire your imagination.
- Apply a taxonomy of an identified online resource to a set of (or possibly all) implementations.
- Apply existing program analysis technology to a set of (or possibly all) implementations.
You may have a look at known 101companies Challenges, but some of these challenges may be too hard and all of these challenges require effort to turn them into proper proposals.
You may also work through the existing 101companies Implementations in search of implementation issues that may may be identified, but, again, some of these issues may be too hard and all of these issues require effort to turn them into proper proposals. (Not too many implementations state issues explicitly yet at the point of writing.)
Typically, you will sit back and match your interests and your curiosity with what is there and with what you are able to learn over the hackathon's time. Don't be too ambitious. Your contribution does not need to be huge in any sense. Simplicity combined with clarity is king. You want to find something what's definitely useful or at least inspiring, also something that you can complete, perhaps with the help of other teams (yet to be identified).