Pages for every member

[peey]

Basic work on pages for every member.

Some things still left to do, I'll comment about these later.

[peey]

Certain things which need to be sorted out

1. What to do about members data duplication?

We'll have member data in both the members collection / _members folder and members.md.

I don't expect everyone to make their byld pages. But we need to mandatorily keep a list of members on the website (required by the SC, plus we'd want to do it as a club for reasons of transparency).

So perhaps we should leave the duplication be - one data is meant for the members table and the other is meant for their page. We don't require stuff like email, facebook etc to be on their page anyways (yet)

We could also link the data in both places by some sort of 'id' (their email?)

2. What to disallow / allow in member's own content?

I think we should allow arbitary HTML (including script tags) because people could put things like

1. Badges,
2. Mini-games or something they made

But we don't want to allow things like

1. Fiddling with rest of the page's CSS
2. Scripts which aren't for widgets and aren't js libraries on cdns (we'd run into xss security issues otherwise) etc.
3. Twitter feed / any feed with custom content. (We might have restrictions on content since IIIT site will be hosted on .iiitd.edu.in subdomain, we can enforce restrictions when PRs come but not when there's content being rendered from external sources)

We need a set of requirements / general guidelines clearly stating what's allowed and what's not allowed. We can always not merge until the requirements have been met.

(and perhaps disallow someone to make their page altogether if they don't abide by rules)

3. What to put above the line?

Every member page has two parts - content above a <hr> line which we'd standardize for everyone to maintain consistency, and content below the <hr> which can have their HTML.

Right now, it's just member's name which I've put above the line. What else should we put? Optional links to linkedin, github / gitlab / bitbucket, stackexchange might be nice.

Member since and to info (we don't have this for historical data)?

4. Where to put the link to member's page?

Clicking on their name in the table could work. Although it may not be apparent at first glance that there is a link to their page

[virresh]

I thought over these points before and had thought of the following framework :

1

This isn't actually a data duplication, all official data will always be maintained within the members.md file

What the pages inside _members/ should do is override the default generated page for members, in case they wish to add more stuff and information / redirect this link to their own website
Also we should be wary that the names can have clashes, so it would be better to support pages in the format: /members/<github_id>.

Also in the default page, what we can have is something like:
(All of this only if the user has updated it's corresponding entry themselves in the memebers.md by sending a PR, since otherwise the page has no value as such, and maybe we can have a variable called page_visible, which controls whether the corresponding entry is made or not, probably we need a ruby script for this)

• a github profile card such as one from here: http://lab.lepture.com/github-cards/
• a linkedin badge
• a twitter stream
• stackoverflow badges
• (G+ via email / fb badges maybe ?)
  (all of the above as a default template which needs no customisation)
  This should incentivise people from adding their information by themselves

2

Definitely agree, we always have a manual inspection before allowing them to merge it, and we can probably document it somewhere

3

I think lets keep the above <hr> stuff minimalistic and have their names, emails and a profile picture (taken from maybe gravatar or gh-profile), position (admin / member / alumni)
I think adding a from and since would be troublesome and will require manual inspection
Though it would be a great addition if someone can do it for us (maybe open this problem for someone to enhance the website later on ?)

4

Continuing from point 1, I think we can add another icon in the tables that will be present for all members, in case they have provided a custom website, we redirect to that, else we redirect to the member pages built above.

[virresh]

Probably you can combine this and the above clause using an or conditional ?

[peey]

They load different CSS files.

Besides, I'm thinking about removing this. I don't think this should be in includes, instead how about this - head include just has the common tags and css tags common to all pages. It doesn't have <head> so you wrap the include in a <head> tag and then you can also add stuff to head from the page which is including (layout-specific css files and titles, for instance)

[virresh]

What I meant here was to combine the css files since I didn't see any conflicting rules
But probably it's better this way only

Also about the tag:
We probably can allow that, but the other alternative could be allowing them to specify a page variable that is used to load css files in here
And let the rest of the stuff be as it is (thus it eliminates these if conditionals

[peey]

Yes but it's unnecessary coupling between the modules.

That way, modules need to be aware about this API which the header include provides, and then header needs to be updated whenever anything which depends on it is updated to add a new rule.

I think this is an anti-pattern, when we can have it without coupling - you just include common things and all custom things go in their own layout files. Logic stays more local

[virresh]

Alright, let's go for it then 👍
The only reason I wanted header to be an include was my personal mistrust towards users that they will not include the common files (it's too much work for most to read a documentation properly),
And usually they end up with certain bugs
header as an include enforces things a little more strictly

[peey]

Cool. Though anyone working on source would def have to include all the common contents of the head because of bootstrap and favicon, hopefully that provides some defense

[peey]

Will merge after doing this

[peey]

default generated page for members

What is the purpose of this? We should discuss this because adding this requires a lot of extra technical work (custom script to generate these, decide what to put in default pages (the list you provided), then provide support for each of those options, also provide support for turning each of them off or on, also provide support for keeping one in the table but not on the default generated page (e.g. github))

One point I can think of in favor of it is that people might be lazy and would rather add data instead of adding their page. But then should they have their own page or does the members' table suffice?

Also, what is the purpose of member pages in general? This is something we should discuss. What I was thinking about this is - it's sort of like a privilege we're giving them - their own customizable space on Byld's website. I think primary audience for this would be others at IIITD, and people who randomly stumble upon their page when googling their name / username, and their friends who they give this link to. So the idea of having a linkedin badge etc doesn't make sense to me at first

Stuff we can encourage them to put on their page:

• About their interests
• Details about what they've bylt

[virresh]

privilege we're giving them - their own customizable space on Byld's website

Yep, this is the whole motivation for having it hosted on our servers
The list I suggested is just indicative, and probably people don't update their projects themselves once the page is made (due to sheer laziness as I have seen), so the motive behind default page was to give them something with the least efforts consisting of stuff that is capable of self-updates with minimal work on either side

Issues with requiring every member to add their own .md page:

1. People are lazy
2. If they can make a page for themselves on our site, wouldn't they opt for a full fledged website of their own hosted on gitlab or github pages which offers no limitation to them
3. If we are supplying them templates, then a variety is always better imo, but yes if technical details are a road-block, probably let's just roll out the ball to the members and make them responsible for their content

Stuff we can encourage them to put on their page:

• About their interests
• Details about what they've bylt

Definitely we want people to put these up, and possibly keep them motivated to update this page with their latest projects etc

I have a vague idea in mind as of now, and the purpose of having a default page was that it would make people have a psychological backup that they can just let the current one be default and update it as they build stuff instead of having to keep things blank at first,
(Seriously speaking, most existing byld members won't be much interested in building their own pages, they already must be having stuff like gh-pages, this attraction would hold true for most of the newcomers, and these guys would need to have some examples already in order to be motivated to build their own page under byld)

For starters, I wouldn't worry about providing options to hide stuff that they havent put up on the members table
If they provide a github account username, and choose to not override the default content, well we are supposed to use that username (same with twitter ids or other stuff they might add in the members.md page)
And in case they don't, we don't render the corresponding stuff on the page, (hopefully easy to check if a variable is assigned a value or not in yaml)

[virresh]

Alright, let's go for it then 👍
The only reason I wanted header to be an include was my personal mistrust towards users that they will not include the common files (it's too much work for most to read a documentation properly),
And usually they end up with certain bugs
header as an include enforces things a little more strictly

[peey]

Since senior members of Byld would likely have websites and homepages of their own, there's not much value of having a homepage on Byld. So for them, we could suggest that they write a few things about their time with byld and perhaps about the projects they did.

Newcomers would be quite interested in reading such things, and it helps highlight the kind of work people in Byld do, and also motivates people to join Byld / do cool stuff once they join Byld.

[peey]

I'll send a separate PR for refactoring, possibly coupled with https://github.com/virresh/byldWebsite/issues/28 because there are some more areas where I think we should move things around, so discussion on that should be separate.