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.

[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)

[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.