Meeting Minutes: September 7, 2014

Introduction

Welcome! Congratulations, you’ve joined the best team.

How things generally go in these meetings:

  1. Opening announcements
  2. Round-robin to give each student time to ask questions
  3. Closing announcements

m_conley is posting meeting minutes this week (and posting them late – sorry).

These meeting minutes are going to be pretty extensive. Most minutes should look like this.

Mentors

  • ChipX86 (Christian Hammond)
  • heapify (Anselina Chia)
  • m_conley (Mike Conley)
  • purple_cow (David Trowbridge)
  • smacleod (Steven MacLeod)

Students

  • andrewhong (Andrew Hong)
  • asalahli (Azad Salahli)
  • brennie (Barret Rennie)
  • dkus (David Kus)
  • justy777 (Justin Maillet)
  • mloyzer (Mark Loyzer)
  • nicole_xin (Nicole Xin)
  • rdone_ (Ryan Done)

andrewhong and nicole_xin are absent this week due to traveling.

Getting going

Your primary goal right now is to get your development environment set up, and if you’ve got it set up, then you should be looking for EasyFix bugs to fix. Claim a bug by commenting in the bug saying that you’re taking it. Don’t take any bugs that have been claimed by other students from this semester. If you see a comment claiming an EasyFix and the name isn’t in the list above, it’s probably fair game (feel free to ask if you’re not sure).

EasyFix bugs are your onramp, and then we’ll get you assigned to some larger projects. Here’s our current project list for your perusal.

Projects are worked on by one student at a time – we generally do not put students on teams on the same project, as we find these hard to evaluate.

Project selection will probably occur at the sprint.

OMG Ask Questions. Also, we’re human.

This cannot be overstated. If you want to survive this course, you need to ask questions when you’re stuck. If you are stuck, if your are immobile, do not just stew there hoping the solution to come to you. Try a few things, and if you cannot figure it out, just ask one of your mentors in #reviewboard-students. We’re here to help you and answer your questions. Use us. Help us… help you. Help us… help you.

Also, we’re human. Don’t be afraid to talk to us. We’re friendly. Don’t be intimidated by us. We also make mistakes and get stuck and ask each other for help. Ask questions and you will not be thought of as silly or foolish. Just ask!

We’re here to help you. We are friendly people who love to help. It’s our job to help you, and we like that job! Let us do our jobs and ask!

Also, don’t wait until meetings to ask us. Ask us when you’re stuck. “Ping” us in IRC.

Start by asking in IRC. We might be AFK, in which case, we’ll respond when we get back (this works really well if you have a bouncer – ask one of us to get one). If you’re trying to get feedback, the reviewboard-dev mailing list is a good idea – that’s the mailing list for the wider Review Board development community. They’re good folk.

UCOSP / admin stuff should go to the reviewboard-students list.

Direct email or private IRC to one of us mentors is a last-resort sort of thing, and should be for things that you want to keep private. Otherwise, put it in the open – that way, us mentors don’t get out of sync.

Other questions

Q: Do you have a link to a django tutorial? or documentation that would help us get going?

Yes, here ya go. Tutorial is in there too. Make sure you’re reading the right version (check bottom right corner – current is 1.6). Also, check out the blog posts that have been written by past students on this blog. Your Welcome Packet linked to some decent posts.

Q: What version of Python does this project use?

Python 2.6 and 2.7 for Review Board. RBTools runs on Python 2.5 – 2.7.

2.7 is a good bet for your work, just don’t do anything 2.7-specific.

Q: Are there any plans to support Python 3?

Yes, we’ve done initial porting work, but not much testing. We’ve gotta move with the dependencies of our install base, so as more people adopt Python 3, we’ll take supporting Python 3 more seriously.

Q: Are there documents anywhere on code organization? Especially the Javascript bits?

We don’t, no. 😦

We re-wrote the entire JS codebase for 2.0, and we’re still shuffling things around.

When exploring the codebase, maybe take notes which could help seed such documentation.

Q: Do we post WIPs as review requests?

Yes. Please prefix the summary with [WIP]. Any review requests you create should be in the “students” group.

Q: Is the django (or the rest of the code base) in the same docs situation?

Sadly, yes. We do have a lot of documentation inline – docstrings in classes and functions. We’ve found that documentation that’s not part of your codebase gets out of date very quickly – and out-of-date / incorrect documentation can be worse than no documentation sometimes.

We might give a whirlwind tour of the codebase during the sprint.

Djblets and Review Board are divided into modules (“apps” in Django terminology), and are named in ways that help you locate where your code belongs – “diffviewer”, for example.

Git grep is your friend.

You’ll get familiar with the parts you’ll start working on, and we’ll be able to direct you to the right places if you’re unsure.

Q: Do we add ourselves to AUTHORS?

Feel free to do that with your first change.

On project specifications

As software development students, you’ve all probably written a bunch of code for courses, and the specs you’ve probably written that code from have probably been pretty well defined.

This course is different. Review Board is a real product used by real users. We have to be pragmatic about projects. Pragmatic means coming to terms with the fact that things change, nobody can predict the future accurately, and nobody is perfect.

You might hit a deadend with your project that we didn’t foresee. It’s not super-common, but it happens. If that happens, we’ll move you onto a different project while we take the spec back to the drawing board. That’s just how the industry works sometimes.

Because some parts of the spec may be vague on our part, you may get really excited about a direction you want to take the project. That’s a very good thing, but please run it by us first. if you encounter a problem with the design or some unknown, and have an alternative way you want to go about it, talk to us before you do too much work on it. sometimes what may seem challenging has a simple solution, and sometimes a different direction will actually conflict with something else that’s going on elsewhere in the code.

The weekly meeting is a great opportunity to stay in sync with what the other students are doing to make sure what you’re doing gels with them.

Misc

  • Review Board is not a traditional Django project. We use a lot of Django conventions in some places, but in other places we completely alter how Django works for our purposes.
  • Hackpad is where you can take public notes. Get yourself a free account there. When you work on a project, we expect you to keep a Hackpad with notes. File any pads you create under the “Students” category.
  • Some EasyFix bugs might turn out not to be so easy. That’s still useful information, but come talk to us when that happens.
  • We’ll give you a t-shirt at the sprint if and once you’ve put up your first review request!

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s