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.
[email protected] 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