Karen Reid sent a message asking you to make short videos about yourselves talking about your sprint experience. You should do it ASAP while the sprint is fresh in your minds.
If any of you, at any time, are blocked entirely on code review, come talk to us, ASAP. One of our primary purposes as mentors is not just to answer questions, but clear things out of the way. Gentle pestering is the recommended approach.
You’re not prevented from writing blog posts outside of your scheduled day. You can blog every week if you want.
For making time estimates for our work, do we make up tasks we think we have to do then estimate time for that task alone?
More or less. You can have something like
“Create empty pages in the admin for security stuff: 4 hours”. A plan is better than no plan. It is entirely realistic to have your time estimates will be off. A rule of thumb we often used was:
1) Figure out how long you think it might be
2) Factor in time for reviews, questions, getting stuck, needing to make requested fixes (this will all be a guess)
3) Double that 🙂
Breaking down your project into subtasks is a good exercise and it’ll give you a sense of scale of things and a map to follow.
Where are we posting our tasks/estimates?
The blog (https://reviewboardstudents.wordpress.com/ ) or hackpad (https://reviewboard.hackpad.com/).
How much detail is expected for the mockups?
We are looking for quick sketches, nothing pixel-perfect. Wireframes, drawings in a notepad are fine. If we need more detail, we’ll ask. UI-heavy things like the checklist extension probably require more thought.
Do we have to post the mockups for a review request?
I recommend it. It’s a great way of bolstering a review request, and clearing up what a review request is proposing. It’s especially useful if you are looking for feedback on your designs. Everyone can post “just screenshots” as review requests. You can do so by going to https://reviews.reviewboard.org/r/new/ and at the top of the left column choosing “None – File attachments only”
There is no distinct formal process in place but posting screenshots to Review Board has distinct advantages, the main one being that comments can be added to regions of the screenshot.
Either way, the goal is to show what you’re thinking, so we can give a better feedback.
Down the line, when you have patches that make changes, it’d be good to attach screenshots showing what the patch is actually doing. When writing a spec it’s always good to have your mockups on the hackpad for the spec. Posting them on Review Board to get feedback is fine as well. It’s up to you how you want to do this. It’s your project.
In https://reviewboardstudents.wordpress.com/calendar/ soft pencils are down is on Dec 1 and hard pencils are down is on Dec 3. I remember something being mentioned about this at the sprint. Could you explain it again please?
“Pencil’s Down” is when your project should be in a state where they’re either ready to merge, or (if you didn’t get as far as you originally thought) ready to be handed off to someone else. In either case, they need to have gone through some review at that point.
Since reviews can take sometime, especially with 5 students and large projects, so you should budget in time for that.
To be on the super-safe side, have the “final” version of your code out of WIP and ready for serious review somewhere around a week before firm pencil’s down. We need to have gone through your code, tested it, and shepherded it into a good state if you want a chance at a decent evaluation.
So soft pencil’s down is kind of like a warning. If you’ve hit that point and no code is being reviewed, that’s not good. Hard pencil’s down is the 100% serious cut-off point.
Hard-pencils down is the very last chance to submit code review if you want it factored into your evaluation.
We might do a review, then you fix stuff up, we do another review and keep iterating like that. We will be doing that until pencil’s down.
Pencil’s down is the last day for that iteration to occur, and we should be at a pretty stable point. Like, if on or near Pencil’s down, we go “This needs a architectural overhaul”, there’s been a serious failure on our part. It should mostly be little fix-ups.
So you don’t review individual task completion so much as the project as a whole?
That depends on the how you break up the project. For instance, you might write the foundation for something that can do security checks, without implementing all the checks. That can be reviewed and go in. Then you could implement a set of checks, and that can go in.
We can (and want to) do WIP patch reviews all the way up to the end of your project.
In the calendar, some of the Tuesdays are for some of us to post blogs. What should the blogs be about?
UCOSP requires you to do some writing as part of this course. What we ask is that you write something about your experience working on this project that’s suitable for a technical audience that might not be 100% familiar with the internals of Review Board. You might talk about a tool you’ve been using or a bug you’ve had to fix, and how you went about figuring it out.
UCOSP uses this is two ways:
1) To get a writing sample which they can evaluate as part of your final grade recommendation
2) To post on the UCOSP blog to show prospective projects, mentors, sponsors and universities to show that this stuff does work and that you do learn.
If you need inspiration, or aren’t sure what kind of material to write about, you can just look at previous student posts.
There is no activity shown on my github account. Is there a reason for that?
I believe it takes a little while. I think github handles these things asynchronously for the first commit, so it won’t know you committed until it has swept that project, which it only does every once in a while. But after the first one, it knows you’ve committed there, so it gets updated automatically.
If a task is going to take me 4 hours to code… and then I want to factor in review time, but there may be like a week of lag time between when i post it and when it’s reviewed, am I now estimating a week?
No, unless that task is blocking you from working on something else.
Since you’re using git, you should be able to continue your work (generally on a new branch off the branch for the change that’s up for review).
Realistically, do students generally complete just the one project during the semester?
It’s really hard to make a general statement about that as it varies wildly. Every student is different, every project is different. Some students work on one project the whole semester while others are able to knock off a few projects. In some rate cases some students completed the project after the semester was complete (in which case, it was known beforehand). It’s really dependent on the student and the project. Sometimes these projects hit into problem areas we didn’t really intend.
It is not a race to see who can finish the most projects.
Schedule your project realistically. If it seems like it shouldn’t take up the whole semester, plan to have a second one. Try not to artificially make that projects take the whole semester.
I have questions about the requirements for the rbtools command (for creating .reviewboardrc files) I’m working on. The code I’ve written so far takes in options for the server URL, repository, and branch, and creates a .reviewboardrc in the cwd. I could use some direction as to where to go from here.
Having it ask questions would be good, if you don’t pass options. Along with that, I’d love some options to make it easy to create a .reviewboardrc for RBCommonds.com. I can help you with what’s needed for that.
The RB URL will need to be manually entered. The repository name should optimistically be determined, based on what repositories are known on that server and the current checkout’s settings.
If it can’t be auto-determined, or if there are multiple options, it should ask.
RBCommons is out hosting service for Review Board installs for small businesses, classes, etc. http://rbcommons.com/
Ignore TREES, we we’ll probably nuke it by version 1.0.
I’m not sure if my blog post is up to par. I’m the first one to write one so I didn’t have as much stuff to blog about.
I think it’s pretty good. I actually expected a post about your sprint experience. But it definitely serves the purpose of helping UCOSP determine your writing abilities. It’s also good data to have on the blog the next time someone is setting up PyCharm.