Alumni portal milestone 1 master blueprint

[rushiagr]

This blueprint is to provide a high-level description of what is needed for the first milestone in the process of development of alumni portal. A new issue should be created for each of the smaller chunks of tasks, and this issue (which essentially is acting as a master blueprint) should be closed only at the end of milestone, when all the constituent subtasks are reasonably implemented.

It is being decided that in the first iteration (let's call it our first 'milestone'), these are the things which should be implemented in the alumni portal: An alumni should be able to register itself to the portal, by filling all the required information, so that we can create a database of them and use it in the future to assist alumni-alumni interactions and student-alumni interactions. We will also provide an optional 'donate' button, where an alumni can donate an amount to the alumni association fund. Donations will be anonymous as of now. There will be facility in the portal to create and attend events. Admission to event can require a small fee. So our portal should be able to handle registration to the event using that payment gateway.

Following sections will describe things in a bit more detail.

Login: Registration to the alumni portal will be allowed only via the official iith email ID. This means we'll need 'login with gmail' integration, with proper validation in place to make sure that only IITH students log in. Note that the first batch don't have their roll numbers, but their names as the email.

Registration: Registration should be as simple as possible. We are already asking everyone to log in only via their IITH email id (which might be painful for people who no longer use that account actively), so we should take care that we don't add anything which makes the use of portal any more painful. We should autofill all the fields which we can get already from the IITH email address (e.g. cs08b001@iith.ac.in implies CSE branch, B.Tech, year of passing 2012, and roll number 1).

Mandatory and optional fields: Registration form shouldn't be pages and pages long. We are going to split it into pages, with each page only containing a few fields (more like a step-by-step registration form). We'll add a bar which says how much percentage of the form is completed. More importantly, only the first page of the step by step process is going to be mandatory to complete the registration. At the end of first page, we should say something on the lines of 'All the information required to create your account is complete. You can fill rest of the information later too'. If the user stops/logs out/disconnects the internet before submitting the first page, all the information related to that user will be removed from database (if stored), so that he can start over again next time. If the user finishes first page, but not the subsequent pages, he will be shown a red banner on top of his profile which will say '40% of profile information still not filled', or something similar.

Mandatory fields: name, IITH roll number, passing year, department, course (btech/mtech/etc), current job/university (optional?), 'bigger umbrella' of your current job/university (e.g. defence, IT for jobs, CS/electrical for higher studies). This last part need more concrete discussion and suggestions are welcome.

Payments integration: Need payment gateway integration for accepting donation. Donations will be optional, and registration will be free. Also in the first milestone, we will require creating an event, participation in which should require a fee paid via this online payments gateway. How to have this feature is not comprehensively discussed. More information regarding this will be added as the idea gets converted to a more detailed specification (and if you have any comments/ideas, welcome!)

Technologies: In order to allow rapid pace of implementation, we'll use things which are known to assist the same. We'll start with bootstrap or bootstrap-like framework for UI. Django will be the backend framework (as the lead Abhay is comfortable enough with it). We'll use MySQL as our database. PostgreSQL should be fine too.

Ideology: We should strive for a agile-like software development methodology-- set a deadline and try to make a minimum viable, shippable product at the end of it. One of the benefit of such an approach would be that we will be forced to not spend a lot of time on only one aspect of the project (e.g. too much time spent in beautifying the user interface resulting in not implementing payments integration at all)

Final thoughts: This is in no way a dictatorship. Everyone's ideas are welcome. Somebody has to start it so me and some of the other alumni and a couple of current students started it. Feel free to let your opinions known to everybody. Don't hesitate to debate, even disagree, if you think it will help the project. Make sure you keep the bigger picture at the back of your mind always. We are more than welcome to have you participate in it. We are more than welcome to add you to the 'we' :)

[tanmay-gp]

Any update on the development/ design?

[rushiagr]

Nope. Things didn't work out as we expected. It's now going to be offered as a winter internship project to the students. Let's see how far it goes this time around..

[tanmay-gp]

Can Infero take this up?

[rushiagr]

@tanmay-gp91 sure! Sorry, it took some time to decide how the alumni is going forward with the task at hand.

Two students from IITH are selected, who will be the primary implementer of the Alumni Portal. As it is all going to be on Github, it will be open for all. And in fact, we'll all benefit if more people are interested in getting this done, and provide their valuable feedback along the way.. :)

[gouthamve]

As all progress is going to be tracked using issues, I think its best if we start discussing everything by creating an issue also, all issues need to be tracked using milestones and labels. And when we do that, there will be a lot of issues floating around, but it will keep everything open and will help new contributions.

Also then we will need a tool track the issues. I found that this tool: waffle.io (example project: https://waffle.io/reactioncommerce/reaction) works best. It is completely free for open-source project.

And we need each feature no matter how small to be added as a specific issue. It can be assigned and labeled. So, when a newbie comes in, he will see some small issues he can start working with. This will get him familiar with the codebase and will set him up for bigger contributions. Solves part of #14

What do you think?

Ty, @gouthamve

[ajayaa]

Good suggestion Goutham. But as of now we are not going to use another tool to do issue tracking. It is going to be done with github issues only.

[gouthamve]

Oh sorry for the miscommunication, waffle is not separate from GitHub issues. Only github issues show up in waffle. The current page for the alumni-portal looks like this: https://waffle.io/IITH/alumni-portal

You can login and start assigning labels and roles from there. It provides a high-level view of what is happening and will make this project more agile.

The above link should be referenced in the Readme.

Ty, @gouthamve