If you wish to cite the iP in your resume, you can do more to make it look more impressive to a potential employer. These improvements are not considered for grading and can be done after the semester is over. Some ideas:
On a somewhat related note, you can also create similar product websites for your other projects (projects from other modules, pet projects).
Start using Git via the CLI
If you have been using SourceTree (or other GUI) for Git before, we strongly recommend that you move towards using the CLI to perform Git tasks in the second half of the semester. Doing so will strengthen your Git knowledge (because CLI takes you closer to what's actually happening, while GUIs might hide such details).
But you can continue to use your favorite Git GUI for a more 'visual' view of your repo, side-by-side with the CLI e.g., from SourceTree, you can open a gitbash terminal, run the command in that terminal, and see the result in the GUI.
v1.1, as explained in the pane below.
Recommended procedure for updating docs:
Lookout for these mistakes which were the most common in previous runs of the module:
Update the following pages in your project repo:
/docsfolder) is used for module admin purposes. Please follow the format closely or else our scripts will not be able to give credit for your work.
README page: Update it to match your project.
Add a UI mockup of your intended final product.
Note that the image of the UI should be
docs/images/Ui.png so that it can be downloaded by our scripts. Limit the file to contain one screenshot/mockup only and ensure the new image is roughly the same
height x width proportions as the original one. Reason: when we compile these images from all teams into one page (example), yours should not look out of place.
If you did the above update correctly, UI mock up and profile photos should appear in your project website and this Project List Page.
Update all contents to match your own project.
Update the link of the GitHub Actions build status badge () so that it reflects the build status of your team repo.
Acknowledge the original source of the code e.g.,
This project is based on the AddressBook-Level3 project created by the [SE-EDU initiative](https://se-education.org).
Update site-wide settings as described in the guide Using Jekyll for project documentation @SE-EDU/guides.
docs\_sass\minima\_base.scss needs updating too (it comes into play when you convert documentation to PDF formats).
## Archiving contacts [coming soon]).
At the end of the project, each member needs to create a Project Portfolio Page (PPP) to describe your contribution to the project. Let's create a skeletal version of the PPP now itself so that everyone becomes aware how detailed you need to be abut your individual contributions at the end of the project.
to be added soonas placeholders for content.
Add the following to the DG, based on your project notes from the previous weeks.
Some examples of these can be found in the AB3 Developer Guide.
The above DG sections should cover the full requirements of the product, some of which might not even get implemented by the end of this semester i.e., do not limit to just the requirements you intend to implement in the next iteration. Reason: All identified requirements need to be documented for future reference.
Furthermore, these sections will be graded at the final project evaluation, and any bugs in the content can cost you marks at that point. The panel below gives some relevant DG bug examples you can lookout for:
show a place holder for photo, showing a generic default imageshould be assigned to Jake and to milestone
v1.2and the second one
v1.2bso that the dashboard can track them accurately. The reason for naming the earlier milestone as
v1.2is so that even if you fail to finish the second one, you can still get credit for reaching
v1.2(which is the milestone tracked by grading scripts) -- think of the first iteration as minimal deliverables for
v1.2and the second one as containing do-if-there-is-time improvements.