- Mike: Status reports didn’t work well this week. Reasons:
- – Gabriel dropped the course in the middle of collecting them.
- – Only a few were sent to the mailing list.
- Mike emphasizes we should keep an eye on the calendar. https://reviewboardstudents.wordpress.com/calendar/
- Mike announces: This week is great to post [WIP] code, even if it’s broken.
- ChipX86 announces: There are now 2 unit test suites, one for Python and one for JS. The JS one is at http://localhost:8080/js-tests/. He also mentions everyone should get familar with writing unit tests.
- All expected people are present.
- Niklas asks about RR editing permissions set for users which don’t become visible; we agree to figure it out after the meeting.
- Niklas also asks if somebody can explain how post-review –revsion-range works on SVN, also after meeting.
- Concerning Markdown integration, ChipX86 thinks there’s far too much focus on making all this optional (settings, extensions). He suggests a single flag setting if comments, descriptions and so on are “rich” or not, default false.
- We need database evolution for this, ChipX86 suggests to add a column to all things, setting markdown=false for existing posts. Greg argues that this might add a lot of data; the consensus is that this extra data is quite small in comparison and space is cheap.
- It is agreed that we need a boolean per post to say if it was created with Markdown or not. ChipX86 suggests that users should not be able to toggle Markdown per post – everything new shall be Markdown.
- smacleod asks if this should go in review-requests’ “extra_data”; ChipX86 finds it harder to manage and not easy to populate with a default.
- ChipX86 mentions that for Markdown previews, there is http://code.google.com/p/pagedown/wiki/PageDown. Greg has already looked at it and tries to integrate it. ChipX86 also mentions to consider markdown2 on the Python side, Niklas mentions Github-flavoured Markdown being a good fit for dealing with code, but it’s unclear so far if there is a JS library for previews.
- We agree that with client-side only JS Markdown rendering, we must pay attention to not make the content jump when text is being rendered as Markdown (alternatives are spinners to wait until rendering is done).
- Felix says he feels awkward with Django and suggests going through the Django tutorial before starting work. Mike says that we shall try to get Felix’s setup run as soon as possible, and that he shall ping as soon as there are difficulties.
- Surya posts 4 minute video about the extension browser he made (http://www.youtube.com/watch?v=Xvntl7ksjPA&hd=1). We agree on that this is awesome.
– Q (Katkat): Working on ReviewRequestDataGrid, question: Is this meant to be just a list of the review requests the user has done reviews for, or should it include data on the reviews themselves too (like the date the review was submitted or something)?
A: A good start is just listing the reviews that a user has written. Might be a good idea to brainstorm some interesting columns we can add too. Other suggestions: the date it was submitted, how many issues were opened, whether or not they gave a ship-it, if any issues are still unresolved.