IRC Nick -> IRL Name Mappings
aam1r = Aamir Mansoor
Allyshia = Allyshia Sewdat
ChipX86 = Christian Hammond
johns187 = John Sintal
jzamb = Jesus Zambrano
Karl-L = Karl Leuschen
m_conley = Mike Conley
Michee = Michelle Chuang
purple_cow = David Trowbridge
slchen = Sampson Chen
smacleod = Steven MacLeod
tahnok = Wesley Ellis
yangtina = Tina Yang
- The project list is here.
- Students are permitted and encouraged to suggest their own ideas as well.
- Students will be working on projects individually. Some projects may be related to one another, but they should be distinct from student to student.
- Project selections should be finalized before the sprint.
- Sampson’s co-op this term (RIM) uses Review Board, so he might get some “nice-to-have” project ideas from there.
- Tina and Michelle both worked at Amazon, and might be able to get some more “nice-to-have” project ideas from their colleagues there, since they also use Review Board.
Students expressed interest in the following areas:
Automated Static Analysis
Allyshia, Sampson, Tina
Sampson, Michelle, Aamir, Tina
Inline File Attachments
Michelle, Tina, Sampson
New RBTools Scripts
Repository Auto-Configuration (There’s still a bit to figure out here)
Fewer Page Reloads
Buildbot Integration (Not on project list – found on bug tracker – issue 88)
SSH Key Association
Questions / Answers / Tips
Q: Should we do anything to get started other than reading all the guides on Review Board?
A: The best thing you can do is poke around the code. Just dive in. Pick something off the bug tracker and see if you can do it. Here are some bugs marked EasyFix.
Q: When asking questions, is it best to ask in IRC and then if that doesn’t work, move to the mailing lists?
A: Yes. The IRC channel is great for immediate contact / information. However, sometimes people are AFK. You should still ping and ask your question, so your ping-ee can read it and answer when they get back. You should also get a bouncer set-up so that you are ever-present in IRC. Email ChipX86 to get one. The reviewboard-dev list is also a great way to expose your question to a wider development audience. The reviewboard-ucosp list is better suited for UCOSP related administrative stuff, meeting time switches, sprint questions, etc.
Tip: Blog posts are super awesome. If you get a really great piece of information / tip, blog about it. UCOSP loves blog posts, because it shows the steering committee that you’re learning, and is used as evidence in your evaluation.
Q: Apart from everyone in this chatroom, are there other developers that contribute to Review Board?
A: Yes! We get patches / pull-requests from people out of the blue sometimes. There are people who hack on part of Review Board because of a special interest – like their company uses a particular version control system, and they want improved support. This link shows you all of the review requests currently queued for Review Board, so you can see how many patches are being considered. #reviewboard-students is used primarily by students who are hacking on Review Board, or alumni who have completed their GSoC or UCOSP terms and still feel like hanging out and helping (which is awesome).
Tip: If there are old review requests here that are unanswered and they look interesting, go ahead and take over!
Q: Are we sticking to a Scrum-style method? Will we have set sprint dates?
A: We’re not really using Scrum. We have weekly meetings, status reports, blog posts, and Review Board to track patches. Other than that, we don’t really enforce a structure on how students manage their time / work. We’re pretty hands-off in terms of management. Use whichever method is best for you – if you want to set goals / sprint dates, go for it!
Tip: Let us know when things get hairy – if you’ve hit a roadblock and can’t move, tell us so that we can get you un-stuck. Asking for help is a good idea.
Q: Will there be PCs provided by the sprint?
A: That’s kind of up in the air – it depends on the hosting university. Steven MacLeod will bring a laptop for John to use. Wesley might bring an old laptop too. Sampson might be able to get people onto one of the machines in the MC Lab at UWaterloo.
Q: Can we work on multiple small features instead of a big one?
A: Doing lots of small features is fine, but they should be things that end users will use for their day job (ASCII art ship-it boats are awesome, but probably best as an after-evaluation project).
Tip: On IRC, you get someone’s attention by saying their IRC nick, followed by “ping” – example: purple_cow: ping. If your target doesn’t respond, ask your question anyway, and they’ll answer later when they go through the backscroll.
Q: How long do we research / Google around before we should give up and ask for help?
A: It’s hard to answer. Do a bit of Googling around. If you’re blocked for more than 1 or 2 hours, you should probably ask.
Q: Is there a style guide?
A: Why yes, there is! Also, download the PEP8 script and run your Python code through it to minimize how much knuckle-rapping you get for style on your first review requests!
Q: Does code get committed once a “Ship-It” happens?
A: No – Ship-It just expresses that a reviewer is satisfied with the work. One of your mentors will push your patch. The only time we’ll ever need a pull-request from GitHub is if you’re sending binary files.
Q: What kind of tools / IDEs do you use? Anything in particular you recommend when working in a Django / Python environment?
A: Use whatever is comfortable. A bunch of us use vim. Others use SublimeText2. Use whatever you like.
Tip: Getting Review Board up and running on OSX might be possible, but we don’t go out of our way to support that OS…you might experience breakage at times that we don’t try to solve, so having a Linux VM ready to go is probably a good idea.
Q: If I have Djblets / Review Board / RBTools set up with virtualenv, is there a point in redoing them with virtualenvwrapper?
A: virtualenvwrapper just gives convenience. It’s not mandatory at all.
Q: Could you elaborate a little more on the blogging on WordPress? I know you said posting tips on it would be nice. But is there mandatory things we’ll need to post, aside from status updates collection?
A: There are a few things that you’ll need to post: status reports and meeting minutes (when you’re assigned to do them), and UCOSP blog posts, Everything else is bonus.The UCOSP blog needs articles, and the steering committee asks that each team produce a bunch each semester. You write a blog post about what you’re doing, and what you’ve experienced in a general way – for an audience of people who are technical, but might not know about the guts of Review Board. This helps to “sell” the program to other universities, other projects, and (fingers crossed) more sponsors. Here’s an example post.
Q: When do we write those UCOSP blog posts?
A: Mike will be putting up a schedule for when you need to write your post. You probably each won’t need to write more than one this semester.
Q: If we come across a bug while using Review Board, do we report it in IRC, or do we file a bug?
A: Please file a bug!
Q: Is there a reason why we’re using a combination of GitHub and Google Code?
A: Mostly history. We started out on Google Code before GitHub existed. Switching over fully might be a goal down the road, but we’ve got bigger fish to fry.
Tip: If you hit a bash / script / verbose error and want to share it in IRC, paste it into pastie.org or something similar, and then share the link to it.
- Make sure your t-shirt sizes match your expectations by looking at these sizing charts: Female, Male.