Project Managers

[arneschreuder]

This is the discussion board for and with Project Managers. Your main task is to coordinate, allocate, delegate and communicate. You are responsible for seeing that the sprints are completed.

[LiamBurgess18015001]

Can all the PMs, when they are added to the organiation/repository, please post their name and team name here.

[jonahgasura]

Jonah Gasura, Java

[idzingirai]

Isheanesu Joseph Dzingirai, Ada

[reece-stephenson]

Reece Stephenson, Delphi

[arneschreuder]

I suggest adding this info to the Wiki. There is a page for Class of 2022. Add yourselves there under a Project Managers section.

[10416260]

Sboniso Masilela , BASIC

[ThashilNaidoo]

Hi there. I noticed that the DevOps team is gone. Is this a mistake or is DevOps no longer a required role?

[arneschreuder]

Someone must've deleted it. Just created it again.

[arneschreuder]

@DurandtUys seems to be some api throttling. Give it some cooldown for the day, then try again. Might take a while to get everybody on board. But we will do what can be done for now. Also, looking into loading people in bulk. Perhaps with their API

[arneschreuder]

I logged a request with GitHub to see if they can lift the throttle for us, since everybody needs to be added in the next day or so.

[arneschreuder]

Ticket for reference: https://support.github.com/ticket/personal/0/1526520

[druha4087]

In the case that there is a change of team roles following today (Friday), will PMs be able to request for members to be reassigned to their new role team? @arneschreuder

[arneschreuder]

Permission has now been revoked.

[arneschreuder]

@Zenthon Can you please remove this message. It clutters the discussion.

[u20437863-James-Butler]

Minutes for project manager meeting 3/3/2022

Features:

• Not all features that were proposed will be included into the project to keep a realistic scale. Features proposed will be filtered to a reasonable amount. Some features have been provided in the project specifications and are therefore considered to be necessary to implement either by this year group, or by subsequent year groups in consultation with the project owners.

• It is encouraged that each feature is approached in a way such that it includes back-end, front-end and everything in-between. This is to avoid making certain roles unnecessary. Eg., if the feature does not have any interface and is entirely backend then the UI developer and API engineer may not be used fully.

• Features are to be assigned in a realistic manner as giving a one group an extremely difficult or large feature will detriment their marks.

• Some information that the specification requires the project to include may be in breach of the POPI act of 2020. This may require us to ask users for consent on account creation or may require a form of admission control for non graduates who can view the graduate profiles and their degrees.

• A homepage and/or navigation bar may be necessary but may need to be integrated into multiple teams features.

• A consistent design language should be agreed upon and used throughout the portal. This should include a set of usable icons, colours, etc.

• The nature of this project may require the use of the universities API and it needs to be discussed if this is necessary. Business Analysts are encouraged to research if this is possible or necessary.

Project Managers:

• A calendar should be used in future to schedule meetings as using a WhatsApp group has been less than ideal. GitHub may be used in future to schedule when meetings like this one take place.

• Project manager’s admin rights on the repository will be suspended soon.

• It needs to be determined if creating discussions in the GitHub teams is still possible without these privileges.

• Thabo will also need to ask if he will retain admin rights as head PM in order to resolve small issues with teams and members.

• Project managers are to check if all of their team members have been added to the GitHub organization and if they have been added to the relevant teams. It is also encouraged that they join the discord and WhatsApp groups.

• One team still needs to be added to the GitHub Organization due to an issue with admin rights. Thabo will resolve this.

• The deadline for adding teams has been extended till Monday due to the invite cap on GitHub.

• Project managers are also encouraged to document they’re teams progression through feature development, such as struggles, resolutions to those struggles, milestones, etc.

Business Analysts:

• The head Business Analyst has been elected: Henri van der Grijp

• The BA’s role has been clarified. It is to include investigating security concerns and solutions for the features, securing resources for the teams and negotiating access rights in order to implement the features, and to advise on changes to the features during feature development.

• All BA’s are to keep a copy of their team's suggestions that they proposed as a proof of work for when marking takes place. Please try to give descriptions alongside the features.

• BA’s are encouraged to research how to use overleaf for documentation. Resources for this can be found on the COS301 clickUP page.

• For the feature list an document processor is fine to use, until further information is given by the project owners.

• Adir Miller, PM has a record of the attendance of BAs for this meeting via discord.

General:

• Each team member may have their own roles but it is encouraged that they help other team members in different roles as if an aspect of a feature does not get done then the team suffers.

• Filtering through features:

1. Thabo asked if a small team of BAs could assist him in filtering through the list of features to remove duplicates, etc.

2. This may not be necessary as Henri, BA head has volunteered to filter them and provide the shortlist to Thabo by Saturday evening.

• It may be necessary for Thabo to receive a list of all participants in the course such that he can check if everyone is on the Github repository.

• It was decided that the minutes of this meeting as well as all future PM meetings shall be posted on discord and Github for easy access and record keeping purposes.

• It is encouraged that every participant in this course keep a good record of everything that they do for this project, i.e., meeting attendance, notes from meetings, progress through feature development, good documentation, etc.

• The project owners need to be consulted about how the switching of roles will take place:

1. For members with multiple roles, will both roles change or just one, or will another team member be required to take on two roles?

2. For consistency of leadership, should the project managers keep their roles through the switch and will Thabo stay the head PM or will another need to be elected.

• It was discussed that Overleaf(LaTeX) will be used for general documentation, and that each programmer will document their own code, however, this needs to be confirmed with the project owners.

[arneschreuder]

Use this discussion and just add comments for every meeting minutes uploaded.

[sarah-a-king]

My rough notes from the meeting:

Frameworks already been given in requirements

Suggests against nodemailer

Morgan, Winston (possible overkill)

Features - on the right path.
Break features down (separate into singular specific features).
Don’t underestimate how much work a singular feature is.
Rather focus on a smaller scope and have the opportunity to do it well.

e.g. student profiles has own features (recommended a “widgetized” approach)

Security alone is not a feature - must be implemented in all features

Blockchain is not expected to be implemented - have a team dedicated to it, researching it and working towards that feature

Authentication and authorization (roles and permissions) are singular features (require full teams)

Business logic: e.g. request rejected - cool down time?

Stay as far away from chat as possible - interaction should be fully automated

Recommendations route - not easy, feature on its own

Error handling is not a feature - each feature/team should implement it as part of feature.

BA responsible for dissecting feature and requirements/constraints/defined acceptance criteria for when feature is acceptable to be merged in.

Pick ONE social feature - challenging in terms of monitoring

Rather take a set of 20 most NB features, assign them and implement them in detail.

Use github discussion - provides visibility to project owners! This is very NB.

[u20437863-James-Butler]

Just to add, I have the answered questions that were asked during the BA meeting.

1. Overleaf may not be required for documentation. We want everything centralized on the GitHub so documentation, i.e., requirements can be added to the GitHub wiki.
2. The projects scope only includes cs students from the University of Pretoria. No need to worry about other students or institutions.
3. The POPI act and Uni API questions are for the BAs to figure out.

[arneschreuder]

Great stuff team. I like the visibility. @COS-301/class-of-2022 everybody is allowed to see and discuss in all the discussions. See here above so that you are up to date on movements.

[ThaboJChesane]

Good Afternoon everyone
I hope you are well and in good health

Please make sure that you have invited all your team members to

The class of 2022
Their Role
Create and add them to your team

Also please remind them to accept their invitation because if they don’t we won’t be able to fix after today because we lose admin rights today

[arneschreuder]

@ThaboJChesane since you are class representative, I am making you the only remaining student that is an owner of this repo ok.

[ThaboJChesane]

@arneschreuder Noted

[ThaboJChesane]

@arneschreuder
Is it possible that the Project Manager or Dev op fork the project and create branches instead of every person having their own fork?

[arneschreuder]

I would challenge that in first asking why would you want to do that?

[ThaboJChesane]

@arneschreuder the dev ops team requested I ask you because they it would be simpler that way.

[arneschreuder]

Ok, I will shed some light on the process again on Friday. But the forks are there for a reason. It teaches the students how to really collaborate in a safe way. Every single user should have a single clearly not overlapped thing they work on. Working together on a feature is possible, one could just do upstream branches. But again I challenge this notion. A “feature branch” in the context of this project should be very small incremental improvement to the code in dev. Adding interfaces, small outlines, tests etc. We just have to get through some examples and then it will make sense. You should very much approach this like an open source project

[ThaboJChesane]

Features redo.pdf

[ThaboJChesane]

@arneschreuder Please check our slimed down features
@LiamBurgess18015001 , @ListlessPanda and @MildogMiller
Thank you for your contributions as well

[arneschreuder]

Ok, my feedback here is:

• Login, logout, reset, register, forgot password, reset password, sessions, tokens etc. == Authentication. This is all one feature, but a big feature.
• You describe features as "stories". Where a feature is described in free text. Event storming can be used to help formulate this. So example: in the context of Student Profile Feature: When: a student goes to their profile, Then: They can see, they can do, they can....
• I will provide some high level features that you can use to guide your thinking. I post this list below.
• Do not confuse a feature with a page. A feature speaks about an entire experience a user has with the system, or a capability that a system has.
• Consider that you might need feature that might stretch across teams. These are often plumbing. Take the UI components, libraries, utilities. You typically want to make a library out of those components/utilities so that everybody can use them. Who's responsibility is that? Consider then a team just for UI Components perhaps.

[arneschreuder]

Some suggestion features:

• Authentication (Domain: Identity)
• Authorization (Domain: Identity, Role-Bases, Policy Driven)
• Student Profiles (Domain: Students)
• Company Profiles (Domain: Companies)
• Company Rep Profiles (Domain: Companies)
• Notifications (Email and Push, in-app and native?)
• UI Kit
• Students Explore
• Company Explore
• Admin Interface to Manage Site
• Request for Access (To profile, information, documents)
• Storage (for fileuploads, organisation etc)
• UP Integrations (Academic Record, CS Login)
• Degree Verification (Blockchain end goal, but see what we can do)
• Social Feature such as Student Stories or something
• Someone needs to take responsibility for architecture (think about event driven elements such as: I submit request, request results in email notification)
• Hosting is a topic on its own. Delivery is a feature. This can be debated.
• CI/CD could also be a feature. So if you say a feature of our project is that it deployes with every merge to production, then that is a feature. (Difficult to justify this across team roles, but you get the point).
• Graduates Update/Blog/Integration of Stories
• Libraries. So you can dedicate a team to ensure DRY and SOLID principles are adhered to throughout. This team would help formulate architecture and standardise client libraries etc.
• Think about Mobile. This could be a feature on its own.

Here above are now a number of features to pick from. I suggest use this list. Assign a bullet to each team. Each team then make that topic/feature a heading in the Wiki under Requirements. Keep the feature description informal and story-like. The refinement happens in the design and architecture phases.

[arneschreuder]

I can not stress this enough. Every team will in some way shape or form make a library or API or some interface for other teams to use. That is the nature of collaboration.

[arneschreuder]

After your feature has been allocated to your team. Please go add it to the graduates of class 2022 page on the WIki here: https://github.com/COS-301/graduates/wiki/Class-of-2022 Add team, feature you are working on, who is doing what etc.

[ThaboJChesane]

Hey guys please type your feature description here and I will compile everything and post it to the wiki
(latest 12:00 9 March 2022) Keep it informal and story like as per @arneschreuder request

[arneschreuder]

Authorization, C++

• Once user has logged in user will have permission to add a profile, edit their profile and delete their profile
• User will not have permission to do the above mentioned to another users profile
• if compony profile wants to view a students/graduates profile, the system will check if the account is authorized to do so(if the request to view the students profile has been accepted by the student/graduate)
• Admin rights will be given to admin users only

Consider just for me site roles as a simple discussion. How would one assign these roles? Admin page? You would need to provide all the authorization elements that a feature might need. Read this: https://www.google.com/search?client=safari&rls=en&q=nestjs+authorization&ie=UTF-8&oe=UTF-8 You would need to either come up with an authorization service or some libraries and decorators that other teams can just consume.

[arneschreuder]

Admin Interface:

The admin interface will be implemented to allow site administrators to manage the system through specialised admin accounts. Once an admin logs into such an account - they will have access to all content available on the website that other standard users can see. Additionally, they will have access to the admin toolbar. This will allow the admin user to create any standard user (student/business/business rep) account, create admin accounts, suspend/re-activate standard user accounts (in the case of misconduct), approve/reject the registration of standard user accounts, archive content from the website and edit the site settings. The admin will also be able to assist standard users with changing vital information on their profiles upon agreement with said standard user. Extensive security measures will be implemented to ensure the safe and ethical use of the admin interface.

Looks good. You will need to reach out to the authorization team to determine what role allocation looks like, so that you know who is admin and not. A big part of admin is the logistics. Say a company is interested in the platform, they can register, but probably needs to be verified by some staff member first. How does notifications and logistics flow here. This needs to be documented. For example, person A, from company X, wants to register their company. Upon registration they provide their company's CIPC registration number and a member of staff gets an email (configured? admin page setting?). When a company has been approved, they are notified, when they are declined .... etc.

[ZoeLiebenberg]

Storage, Fortran:

The user and web application will both need storage both locally and externally. Locally that would be the session storage and the latter would be server storage. These would be the two main storage functionalities that the web application would need to have to ensure good data capturing and file storage. Furthermore these storage functions should be able to store different types of data such as JPEG , PDF , TEXT , JSON and many types of data. While giving users ability to upload , download, append and remove data and files uploaded to the web application.

[10416260]

Delivery

This feature is about making sure and taking responsibility of the overall hosting of the application, choosing the suitable platform for hosting and working closely with DevOps team for continuous deployments from development, staging to production.

Document delivery process and manage the environments (development, QA and staging)

[ListlessPanda]

Graduates Update/Integration of Stories Feature - The Radions

This will be a "reel-like" feature where graduates can upload stories/images that other users can view.
The user will have a space on there profile to add/remove stories/images that they want to share on the site.

[druha4087]

@arneschreuder As the Mobile App feature would have countless dependencies on separate features, my team is not sure what we are expected to deliver? Would it be designing the UI and/or flow of the application or something completely different? Please advise

[arneschreuder]

Good question. So I would say the Mobile feature team has the general feature responsibility of PWA functionality. To ensure that the app is installable as a PWA. That is a start. I already added the PWA dependency. There is some work required here. Then I would say the second priority is to ensure mobile friendliness throughout. This has a lot of dependencies as you mentioned. So perhaps work close with the UI Kit team only. There are also certainly things that you would have to think of: offline capability on mobile. This is quite complex, and can be greatly assisted with some stores and libraries etc.

[druha4087]

Thank you, we will look into that then! @arneschreuder

[DurandtUys]

@arneschreuder My team has been given the Architecture feature, I'm just not entirely sure what each member of my team can do on this feature or how we should tackle this feature. Have you got any advice?

[arneschreuder]

HI @DurandtUys ok cool. So architecture has to do with the overall layers and organisation of all the systems and components. You will play a crucial role in the project structure, how libraries are created, documentation of the architecture, which apis are there, which domains are there, which services are there, which repositories are there etc. You will work with CI/CD on deployment. You are responsible for the docker containers at the client and the api apps. You need to make sure that when it is deployed, it is correct. Your team must document the "blue print" for the project. In your team UI Engineer -> responsible for client side organisation, shared libraries organisation etc. API-Engineer -> API is an app on its own, so the Dockerfile for API app + APIs use graphql, so you must make sure that API conforms to the architecture (not just in apps hosted, but also the organisation of the API layer). Services Engineers -> You must make sure all services engineers are using CQRS, they are providing only service layer logic and nothing more, Data Engineer -> You must make sure all the repositories are correct (I can imagine a repository per entity domain), organisation of repositories, making sure that your layer provides an API for the rest to use etc. Tester -> is involved with e2e testing of entire architecture i.e. the client makes calls to the api, that makes calls to the services that makes calls to the repositories that make calls to the DB. Each of those has a set of tests that need to be there. You will need to help determine what effect that has on the testing of the system. Consider health-checks, you need to ask the api-engineers/service-engineers to give you some healthcheck endpoint that you can use to check if services according to architecture is up. What do you do if a service goes down? Is there some alerts? Work with DevOps.

Please do not worry too much that every feature will fill the cookie cutter concept of every role will have clear pieces of code to work on. There is a lot of collaboration on this project. One of the big big big elements that your team has to do is to document the architecture. You do that here: https://github.com/COS-301/graduates/wiki/Architecture . The architecture feature fills the role of system architects. You ensure at a high level that all the services exists that is needed and is implemented, deployed and maintained correctly. This has some impact on code, repository organisation, CI/CD etc.

[Alexander-Muendesi]

@arneschreuder With regards to the CI/CD feature, I was just reviewing what its all about and thought, my team and I are basically doing a lot of DevOps for this feature and there might be potential repeat of stuff if other DevOps members from different teams decide to automate some of the features like automatic testing etc.

So is there like a specific area we should focus on as a feature or we will basically handle all the automated stuff of the repository?

Also with regards to roles I forsee some roles dropping off for my team so would splitting members into say automatic testing role,automatic deployment role etc or something along those lines be fine

Lastly since there are going to be automated scripts for testing code am I right in saying that we would have to work with testers to create those tests then we write the scripts that will work with those tests?

[arneschreuder]

Hi @Alexander-Muendesi herewith my feedback:

1. Sure, the affected call is probably the correct one. My only concern is the following. Say there are 2 components, Component A and Component B. Component A calls component B. If changes are made to component B, but component A has end-to-end tests that depend on component B. Will this then be picked up? Not sure.
2. I agree. You now need to PLEASE help me with the PRs, the repo, issues etc. Please look at the PRs I reviewed. I keep making the same comments. I need you guys to help with this please. Especially on the "Please add meta to the PR, please don't update package.json" etc. The remainder of your involvement in the project is to actively help in this regard ok.

W.r.t your last comment. Do not wait for other teams. Set up mock e2e tests. Enhance the workflows to include e2e and make sure it works. In this way, once people actually starts adding e2e tests, they will be tested.

I do have something for you though. See the below screenshot:

Please run for me nx lint --fix. I keep getting to above in the PRs and people don't worry about warnings. Perhaps set the CI/CD to FAIL on warnings. Because this clutters the PRs. Once all the fixes have been made. Make PR please.

[arneschreuder]

@Alexander-Muendesi can I ask your team to investigate if there is a way to fail the PR if there are no meta such as labels, milestones, projects, issues linked to the PR? Im not sure if this is possible or even a good idea, but I keep having to ask for it in the PRs.

[Alexander-Muendesi]

Hi @arneschreuder . Thanks for the feedback. My team will look into doing what you mentioned. We will keep you updated.

[Alexander-Muendesi]

@arneschreuder , with regards to nx lint --fix. I see that most of the warnings are usually to do with "type is defined but never used". Unless I am completely off, I think people intend to use those in future and with nx lint --fix people might have a hard time finding what has been changed. Perhaps asking people to maybe just comment out the parts not currently in use with maybe /* */ so that the warnings dont clutter PRs might work better. Otherwise we would just have to inform people what that nx lint --fix is going to do and they will have to keep it in mind as they work

[arneschreuder]

Hi @Alexander-Muendesi I hear what you say, but the code should not be polluted just because people want to keep code for the feature. They should keep that in a bookmark then.

[ListlessPanda]

@arneschreuder With the Graduates Update/Blog/Integration of Stories feature is it going to be a page where post grads can post updates/blogs in a similar way to twitter? Where other users can scroll through and read them?

Also my team and I aren't 100% sure with what is meant with integration of stories, so some clarification would be extremely appreciated.

[arneschreuder]

Hi @ListlessPanda that is up to you to decide. Please separate the stories from the concept of a blog, because that is a different feature in my eyes on the app. So are you on the social feature? I assume? The blog is more a feature where the CS department can post articles on the graduates etc.

So I was referring to integration of stories like:

• There are multiple students, whos stories do I see, and in what order? Latest first, top first?
• The student's stories might be a widget on their profile, there is some integration to that. So for example, say a student has like a little video/story that introduces themselves, perhaps this can replace the profile picture if a user has done that? Like LinkedIn etc.

So your team's responsibility is to give the system the ability to make stories (camera, capture, store) and provide that as an API, service, etc that other features might consume (student profile) and you have a feature where you have some social page (like you say perhaps like twitter feed or not?)

[ListlessPanda]

@arneschreuder If the blog is a separate feature should my team still make it? And should each grad have a place on there profile where they can make a story, and should that then be displayed on a separate page? Like a feed page where you can view the grads stories and scroll thought them?

[arneschreuder]

So the blog is a separate feature I would say yes. That is a different domain. The blog is like a domain itself. The student is a different domain. So your team just focusses on like "reel-like" stories. I suggest keep it simple. Kinda like how LinkedIn works. If the student has recently uploaded a "story", then show some bar around their profile picture, and when clicking on it, play the story. Perhaps then just a "feed" page, where all the stories are shown. I am sceptical about the feed. Since the feed needs some notion of "whos stories do I want to see". There is not concept of friends and/or connections, so we dont have that "see my friends' posts" recommendations. So I would just do the above (the profile picture thing)

[10416260]

@arneschreuder For my team we got the Hosting feature, so with this one we not entirely sure of how we should actually look at it and work given the different types of roles we have in the team, and again are we just looking on where the entire application should be hosted including the database(s), are we actually required to determine what facilities and platform(s) will be best suited to host and maintain the site, including the mobile app. Thanks

[10416260]

@arneschreuder For my team we got the Hosting feature, so with this one we not entirely sure of how we should actually look at it and work given the different types of roles we have in the team, and again are we just looking on where the entire application should be hosted including the database(s), are we actually required to determine what facilities and platform(s) will be best suited to host and maintain the site, including the mobile app. Thanks

@arneschreuder Just add on this as well, the actually feature is DELIVERY because from your feedback on the features list that's how you classified it. Thanks

[arneschreuder]

Hi @10416260 Im glad you contact me. So yes, Delivery is a whole feature. As a team, the overall goal is to host the api, host the client, pick a platform (I initially thought of DigitalOcean, but AWS, GCP are also there). The trick here is to pick hosting that caters for the UP integration challenges that we have. So you need to speak to that team as well.

I deem the responsibilities of the DELIVERY team to be:

• Take responsibility of overall hosting. This includes the app, the api and the DB.
• Take responsibility with the DevOps team to ensure continuous, regular deployments to development, staging and production (prod will take place once release/1.0.x is merged into master)
• Documenting the delivery process: how to deploy to which environment if one needs to manually deploy.
• You have a huge challenge to solve ito ENVIRONMENTS. We have a develop, staging (QA) and production environment for this project. Each of these has env keys (see GitHub Environment Secrets). These define the env variables per environment. You need to manage this.
• So in the roles:
  • Project Manager -> Same resp as all other teams, manage and coordinate team effort.
  • Business Analyst -> Gather and document requirements w.r.t hosting (so hosting is dependent on UP integration possibilities)
  • Designer -> Helps design mechanism so that one can literally see what is being hosted (version number, health check, version api etc.) Maybe dev is like orange, stage is green and prod is blue. Please consider some status page that can be designed as well. Something like: https://api.twitterstat.us where one can see what services are active in which environment etc.
  • UI-Engineer -> Not much work here other than 1. Any elements that the designer came up with needs to be implemented 2. Responsible to ensure that the app (UI) can even be deployed. Works with DevOps team.
  • API-Engineer -> Consider the status pages above, someone needs to build an API for that. Can also be the person that looks at some external system APIs. Help with deployment of the API app itself.
  • Service Engineer -> Not really needed for this feature, so can consider to drop. Otherwise help with delivery of the API. Can also help with Docker.
  • Data Engineer -> Also not really needed, apart from help maybe with the external APIs data and interfaces. Mostly I need this person to help with delivering DB related migrations, helping with rollbacks if needed etc.
  • DevOps -> By definition this person is responsible for getting the deployment done as part of CI/CD
  • Testers -> Do the post deployment testing as well as documenting how to test the deployment.

Do not worry too much about each role having an exact exact exact thing to do especially w.r.t. code base. The overall goals is delivery/deployment. You do have a responsibility to help at the stage when release needs to be merged into dev. But we can speak about this later.

[10416260]

@arneschreuder Thank you for this, it really helps a lot

[DReddy35]

@arneschreuder We have been given the UI Kit feature. Am I correct in assuming we have the responsibility to design and create all the basic UI components that can then be changed and updated for other features as necessary or are we only to design and manage the UI kit?
ie as other feature teams have their UI done are we managing it all or do we have to come up with the design to be used across the entire system and then give it to the other teams?

[arneschreuder]

You are mostly correct yes. The UI Kit needs to develop UI components and services that can be reused by the rest of the teams. So I already added Angular Material and Tailwind. You can utilise this. So for example. You guys maybe need to provide a navbar, modals, alerts, cards, widget boxes etc. I would very much like the UI Kit team to look at Storybook to showcase the UI kit. That is where your responsibility stops. So essentially, you are making a UI Kit that can be reused and used throughout the app. The Material theme IMPLEMENTATION is your responsibility. The designers will make the designs, but you need to see to it that it is there for the UI Engineers to implement.

[sarah-a-king]

Hi there @arneschreuder. Quick question - is it a requirement to compile our documentation in laTeX? Thanks in advance.

[arneschreuder]

Please no, just the Wiki + Markdown is fine.

[arneschreuder]

The wiki does have revisions, so LaTeX then just provides formatting, which Markdown offers enough of.

[arneschreuder]

@COS-301/project-managers PLEASE get your team to properly review their PRs. I keep repeating the same comments on PRs. The easy ones include:

• Please add meta such as labels, milestone, associated project and linked issue to the PR.
• EVERY PR MUST GO HAND IN HAND WITH AN ISSUE THAT IT IS LINKED TO. PLEASE HELP DRIVE THIS CULTURE.
• Please name the PR title the same as the others (using the notation <emoji>(scope): Subject line

[arneschreuder]

@COS-301/project-managers I am a bit worried about the velocity at which PRs are coming in currently. You and your teams have basically about 18 days left to get your work into the release branch, once it is created. This is not a lot of time people. There is still a LOT of development to do. Talk to me, what is the deal? Why are there no UI PRs yet? Please push your teams, get clarity, estimate and plan. This is your job.

[DurandtUys]

@arneschreuder My team needs a bit of guidance, We as the Architecture team have completed the Architectural design and layout of the project, as well as have finished creating the client and API dockers. Now we feel that there isn't much more we are able to do but assist the other features. Is there anything we have missed or haven't done that we are supposed to?

[TangerineZA]

@arneschreuder is welcome to add onto my commentary here, but I would say for now to perhaps contemplate anything along the lines of future functionality? See if either your team or any other teams have any specific functionality the project may need or want added in the future, and plan and integrate some ideas to simplify that expansion process.

[arneschreuder]

I agree with @TangerineZA . If your BA has signed off on all the acceptance criteria of your feature, then you are done. Do not celebrate yet. It is only done once it is production and it works. Make sure this is the case, otherwise, even as simple as your requirement is, it could go south if things don't work ok :)

Check in with:

• Authorization/authentication is there are any architectural things you need to enforce(SSL, TLS etc if that is needed).
• Delivery team: make sure containers gets built, pushed, deployed, etc.
• CI/CD team: make sure pipelines implement architecture correctly.

[reece-stephenson]

@arneschreuder
Integration (@COS-301/c-1) is requesting that they do the registration feature since it is closely related to integration. My authentication team (@COS-301/delphi ) still has OAuth and our own session implementation as goals for the end of this sprint. Is this acceptable and something that they are able to do given the time frame?

[arneschreuder]

@COS-301/c-1 what is the plan? Registration should sit with the authentication team. Integration should be about user data integration between systems. Not registration?

[u20437863-James-Butler]

There is a bit of overlap between UP integration and Authentication with regards to registering a user, as my team is responsible for getting the email verified as a UP email and getting the student details, documents, etc. The Auth team has told us that the signup component is a lower priority of theirs for this sprint and due to my team only working on temporary measures to get the data from UP this sprint (due to UP not having a workable API for this) we do not have that much coding, mostly documentation and plans for future years. We thought that then we could take over this component entirely as it would give my team more to do than documentation and it would take some of the strain off of the Auth team.

One of the temporary ways to get the student details that we decided on is through user input as it is not possible to get the info from UP presently, so implementing the signup page, or at least the parts relevant to student data was in our plan. Should we go through with our plan, should we work alongside the Auth team on the component, or should we leave the full thing to them?

[arneschreuder]

Hi @u20437863-James-Butler and @ricecakesreece I am fine if your teams can come to an agreement. Take note, for the UP Integration, there are parts of the auth that you can help with:

• Getting auth app tokens (client key and secret) from respective parties and document.
• Splitting the auth between student auth and industry/personnel auth. Take note, there are a lot of overlap here.

Then , even though the UP integration does not have much code to then contribute, I do still expect of you to then implement a mock. Mock for us the UP service and the data we need from there. That means that that service can become an adapter that we just switch over once we can integrate with UP systems. There is a lot of skeleton work and documentation that can be done. If you have a mock of this service in the release, I see that as enough.

[arneschreuder]

@COS-301/project-managers !!IMPORTANT ANNOUNCEMENT!!. On the 15th of April, I will create the release branch. This means that everything that is in the develop branch at 23:59:59 15 April 2022 will be put into the release branch called release/1.0.x. If your feature is NOT IN by then, you run the risk of seriously losing marks for evaluation round 2. Remember, the evaluation is simple, your feature must be in the release in working condition. Now, you still have until 23:59:59 21 April 2022 to make FIXES (yes, not whole features, fixes) to your feature. On the 22nd of April, we will merge the release branch into master and that becomes our version 1.0.0.

[arneschreuder]

More formal communication will go out on this matter, but for the evaluation, you must show:

• Proof of your feature in code, working (or providing the value it should if your feature is not a feature per say)
• Proof of issues, discussions, PRs, commits. Simple bullet points and links, perhaps a few screenshots.
• You should be able to argue any issues, challenges, blockers that came in your way.
• The long and the short: show me what you did. If that is in the release, then you are good to go.

[arneschreuder]

@COS-301/class-of-2022 take note of this comment. I am willing to move it to the 18th of April, since we lost 3 days on the pipeline issue.

[ZoeLiebenberg]

@arneschreuder I am the PM for Fortran, the team responsible for storage. My data engineer has attempted to ask you questions on the data engineers discussion but has received no replies. If possible, could you please look at the discussion and get back to us. Thank you so much

[arneschreuder]

Thanks for following up with me. Apologies. I was on paternity leave and then the repo’s pipeline broke. So I was a bit occupied. Nonetheless. Please let me know if there is anything else?

[arneschreuder]

I did reply @LarisaBothaTuks

[arneschreuder]

Announcement

@COS-301/class-of-2022, @COS-301/project-managers we managed to fix the broken pipeline in our repo. I underestimated how much work it was to find and resolve this issue. To be specific, the fix is here: #512 . I had to do a bunch of stuff to get the repo to work again. So PRs should flow again. This took me much more time that I anticipated, so please lets try not to break it again.

TLDR;

• Repo pipeline is fixes.
• PRs can happen again.
• Make sure to sync with upstream/develop by fetching and pulling.

Fixes made

• Fixing the mess with yarn.lock
• Removing some nasty dependencies
• Reimplementing some libraries:
  • Some api libs where created as nrwl/angular libs instead of nrwl/nest libs.
  • Some client libs where created as nrwl/nest libs instead of nrwl/angular libs.
  • Naming conventions not followed (missing feature, data-access, util, ui, shared,etc.
  • Wrong configurations
  • Some didn't even use the nx generator.
• Fixing the mess in workspace.json and tsconfig.base. json

General Notes:

• These things happen. Don't stress too much.
• Please use yarn and NOT npm
• yarn.lock MUST be committed in the repo. That is how it is SUPPOSED to be.
• If you have a package-lock.json in your repo, you are busy using the wrong tooling.
• Workspace.json is notorious for having some conflicts when creating new libs. PLEASE resolve these conflicts carefully.
• If your PR introduces new dependencies, PLEASE SAY SO and point it out. This is very important to be reviewed and tested.

Enhancements needed:

• @COS-301/go the pipeline has helped a lot. Thanks for this. It does need enhancements to better catch these issues. So here is what I need:
  • We need a workflow to kick off once a new commit is made to develop (this applied to release/1.x and main as well). Should do the same thing as we have for PRs currently. It is to track if the development branch is building, not just PRs.
  • We did not catch the issues soon enough, this happend because of nx's use of caching and cloud. This is both a good and a bad thing. You will see I added the --skip-nx-cache option to the lint, test and build rules. This fixes our issue, but now builds are going to start to take long. So what I suggest is that we stick with using the cache for PRs and use the skip-cache for full builds (commits to dev, release and main)
  • It is always useful to have a "manual" workflow to trigger a workflow for a given branch at any given time.
  • The build, lint, test github action workflows have badges. Please add these to the readme for everybody to see. Please also include test coverage.
  • Please split build, test, lint into seperate "steps". It currently runs as one step. This means we cant really run these in parallel.

Testing

This is a very very very important message. IT DOES NOT COUNT IF YOU ONLY HAVE THE DEFAULT TESTING GENERATED FROM THE TOOLING FOR YOUR FEATURE. THIS IS NOT ENOUGH. YOU NEED TO ACTUALLY TEST ALL YOUR FUNCTIONALITY. Teams have received very bad marks in the past because of this reason. Please spread the work in your teams.

[Alexander-Muendesi]

@arneschreuder

1. "The build, lint, test github action workflows have badges. Please add these to the readme for everybody to see. Please also include test coverage."

With regards to statement above, could you perhaps elaborate on that. Do you mean something like this perhaps : https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/adding-a-workflow-status-badge . We are not really sure what to do there or if you could provide an example of a badge you are referring to

2. We need a workflow to kick off once a new commit is made to develop (this applied to release/1.x and main as well). Should do the same thing as we have for PRs currently. It is to track if the development branch is building, not just PRs.

With regards to the statement above, could you elaborate on that new commit part. Because looking at the events which can trigger a workflow we are not seeing a way to trigger a workflow based on a commit. Do you mean based on "push" perhaps?

[arneschreuder]

Hi @Alexander-Muendesi .

1. The link you provided is exactly what I want. But you can add a build badge that reflects the pipeline state for the latest push/commit to develop (dev), release (staging) and main (prod). Look at the badges at the top of these repos's README: https://github.com/angular/angular and this one has a lot of build badges: https://github.com/tensorflow/tensorflow

2. Correct, sorry for the wrong terminology. So basically the pipeline runs for a PR and when that PR is merged into dev, it is a new push/commit to dev. The pipeline should then run for what is on dev. This way we CI/CD the PR as well as track any breaking things coming into the branches. (Consider some PRs might pass because of the affected thing, but fail later in the pipeline. This is the case we had this weekend when the pipeline broke)

[Alexander-Muendesi]

Hi @arneschreuder . Currently looking for a bit input on the test coverage badge. CI/CD has been researching how to do it but we cant seem to find anything concrete. The majority of what we found seemed to involve adding external packages made by people into repo. Do you have anything you might be able to point us to ?

Lastly for final demo I see one of the requirements is proof of tests. For the CI/CD would that be all the workflow runs in the Actions tab ? Cant really see how we would be writing the conventional unit, integration and other tests for this feature.

[Alexander-Muendesi]

Update: so we managed to get codecov to provide test coverage on a seperate repo as a test. to set it up on the graduates it would require you to create a secret which we could use and perhaps you would make the account with codecov? It does require some additional plugins to be added to repo though. Not sure if this is what you wanted but its the best we could come up with

[sarah-a-king]

@arneschreuder Hi there. Our team is pushing to make progress but the backend engineers have gotten stuck on a particular issue relating the the API layers and we're struggling to move passed it. Is there any chance you would be able to meet with us sometime today to provide some guidance on how to fix the issue? It would be so appreciated. Thanks so much.

[arneschreuder]

Hi @sarah-a-king I can maybe help late tonight or tomorrow night? Like after 21:00. Please send a Google meets link.

[juwiCarrim]

@ricecakesreece ,
Our blog feature needs to identify an admin user to grant them permission to edit the blog. If the user can be authorized as admin, how would we integrate with you to access this information?

[reece-stephenson]

Hi @juwiCarrim,
@COS-301/delphi is doing authentication. From your question it seems you are looking for the authorization feature which is what @COS-301/c-2 is doing.

[Vhulenda88]

Hey @juwiCarrim I'm the PM for authorization, were you helped by any of my team members

[Vhulenda88]

@Alexander-Muendesi my data engineer @Ray-net is having trouble with with testing, is there a way to open docker in GitHub actions and change the location where the database is stored

[Isakvdw]

Apologies for jumping into this conversation. @Vhulenda88 If you need access to the database which runs on 5432, the postgres docker would have to be spun up in the tests which is not currently the case from what I can see so its not simply a case of changing port numbers. @10416260 is PM for the delivery feature I believe.

[Vhulenda88]

@Ray-net

[Vhulenda88]

@10416260 would you be able to help, or do you have another suggestion ?

[10416260]

@Vhulenda88 As discussed and for clarity, at this point there's no environment the data engineer can connect to expect local since there's no hosting environment publicly available

[Vhulenda88]

Okay thank you

[ZoeLiebenberg]

Hi @arneschreuder , I am the PM for storage. Our team would like to create a firebase project that everyone can look at on the actual firebase platform. Should we make an email that everyone could use or do you have an email that can be used to create a firebase project?

[arneschreuder]

@COS-301/class-of-2022 @COS-301/project-managers Reminder that the release branch will be created at 23:59:59. Everything up to that point that is in the develop branch will be put into the release branch (release/1.0.x). We will mark from what is in the release branch and ultimately in master. In the next few days, small fixes will be allowed to the release branch, but that is it.

[arneschreuder]

Release branch has been created. Release starts at commit 4a33168

[rayden96]

Hi @arneschreuder , How will small fixes PRs be done to the release branch? my team needs to fix a typo.

[arneschreuder]

They work the same as the normal PRs, they are just made to the release branch instead of the develop branch. But take note, no new features, libraries being created, dependencies added, nothing like that. Simply fixes.

[rayden96]

Indeed, Its just a spelling fix.

[arneschreuder]

@COS-301/class-of-2022 @COS-301/project-managers

And so the Mini Project is drawing to an end. At 00:00 tonight the release branch is going into main and you will forever be cemented into the history of this project and module. I am extremely proud of what everyone has achieved! Look at you....You did very well. Almost a professional! ;) Well deserved win for everybody. Now make me proud in the capstone projects.

Easter Egg: I added 2x easter eggs somewhere on the repo. Have fun....there is value in finding it.