home ::
syllabus ::
timetable ::
groups ::
moodle ::
video ::
© 2021
Goal: start something that another groups will say "yes, for Project2, we want to finish that".
By the end of September, project1 will deliver:
- something that executes some of your goals,
- a roadmap telling others where to go from here
- all the "bling" (described below) needed to convince another group that they should use your system.
(Hint: do it now!)
Pick something. Code it in any language using any tools you like. But
- everyone on the team has to use the same tools
- all the work has to be shared via Github (public repos, general GH-- not NCSU):
Pick something that was popular last year (look for the things that got most votes).
- Heck, even get a kick start by starting with a project from last year.
What to do? Well pick something:
- Cool:
- Cause you have to impress;
- Not ambitious:
- So you can make significant progress in 4 weeks;
- Not too small:
- So you can impress people with the work;
- Small enough:
- So you can finish;
- Where there is something already running:
- So you get going fast;
- Something the whole team can contribute to
- Work in a language that everyone in the team can handle:
- Work on a problem everyone can understand
If you want to be in the running for "projects that survivie into the next round" your system has to do something better then something else.
- Which means your code has to address some problem in some current system
- And do so in a manner that is quantifiable.
What do these badges mean?
What do these badges mean?
- code coverage percentage:
- stable release version:
- package manager release:
- status of third-party dependencies:
- static code analysis grade:
- SemVer version observance:
- amount of Liberapay donations per week:
- Python package downloads:
- Chrome Web Store extension rating:
- Uptime Robot percentage:
(If you want more badges, see shields.io).
What are the features of the following repos that make them "good"?
- http://docopt.org
- https://github.com/harshitpatel96/GITS
- https://github.com/JuliaImages/ImageInTerminal.jl
- https://github.com/daniruiz/dotfiles
- https://github.com/chalk/chalk
- https://github.com/marcotcr/lime
Your work will be assessed via how many of the Linux Kernel Best Practices (see pages 25,26) you can emulate.
- Reflect on our project1 grading rubric
- Write a 2 page pdf on the commnection between the items in that rubric and the Linux Kernel best practices.
And that document to your repo as docs/proj1rubricComments.pdf. Write the that pdf using
this template
- Not "nearly" this template. This tempalte. Learn Latex. Hit: use overleaf.
- Copy the rubric to a markdown file. Fill it in. Where needed, add links into your repo to justify your answers. And that document to your repo as docs/proj1rubric.md.
| What | Notes |
|---|---|
| Location | Meet however it makes teams most comfortable (in-person, on-line, whatever the team agrees on). |
| Duration | Usually, keep meetings short (exception: long range direction meetings) |
| End of meeting | Always agree on next meeting time before this meeting ends. |
| Review everyone's to do list | |
| Start of meeting | review everyone's to do lists from last meeting |
| Misc | Group members attended group sessions |
| Distrbuted dev model: | decisions made by unanmyous vote |
| group meetings had a round robin speaking order | |
| group meetings had a moderator that managed the round robin | |
| group meeting moderator rotated among the group |