Self-Evaluation: Summarizing the Past Few Years

Now, it's time to summarize all of the work you have done in the last few years. Putting it all together will allow you to evaluate and compare your profile with other students who are studying at the universities or programs you are interested in. Also, there are quite a few people online on various forums and websites who can help you figure out your choices if given a basic understanding of where you stand. None of this is an exact science, and there is no clear formula or combination that applies or ensures your admission, so do not think that getting good or not so good evaluations of your profile are an accurate representation of what's to come. With that in mind, let's look over everything that's needed.

Breaking it Down

There are many things that should be looked at, described in no specific order.

Standardized test scores such as the GRE and TOEFL are the first things you should put together. There serve primarily as elimination criteria and not selection criteria, so while very high scores may not do much more than getting you in the door, mediocre scores will certainly work against you. The range of mediocre to high varies by program which we'll look at later.

University GPA or aggregate is the second thing you should consider. Whichever university you may be in, your absolute undergraduate GPA and more importantly rank in your department can be big positives in your application. If you did not do so well, then aim to get very high scores in the GRE and TOEFL, as this lessens the impact of low GPAs.

The letters of recommendation from your professors or your bosses can make or break things on their own. Suffice to say, these should be accurate representation of you and your relevant work. You will need at least two positive LoRs so make your decisions about whom to ask wisely. Most universities require that at least one of the LoRs is from an academic adviser or professor, so try to keep in touch with one or more of your undergraduate professors once you are working in the industry.

If you have engaged in research work in the past, it will be a huge plus to your application. Published papers are the primary evidence of having pursued a productive research project and these provide a significant boost to your application. If your project did not result in a publication, fret not. Try to get a LoR from your research adviser, clearly mentioning the work you did, and what the end result was. Also, try to have included mentions of the impact of your research in the LoRs.

In continuation, you may have worked on various academic or hobby projects that led to some usable product at the end of it. These, if relevant, should be included in your application as it indicates that you may have practical experience in the domain. Hobby projects in particular demonstrate that you are willing to go beyond the course requirements to pursue your interests. This is very important if you are applying outside of your undergraduate major or if you feel that your university did not offer as many opportunities as you would have liked in the domain of interest.

An alternative to the above is to describe relevant work experience, or parts of your work responsibilities that ascribe to you having the necessary qualities to do well in a graduate program. These included both technical and non-technical attributes. Obviously, work experience in the relevant domain will help your application the most.

Lastly, we come to the extras that while by themselves are not big aids to your application, they help embellish your application by painting a picture of a person who has interests outside of the classroom and lab. Here again, relevant technical experience such as blogging about your technical interests, publishing in magazines, running or participating in a local technical user group, competing provide small bonuses. Non-technical experiences such as organizational work, leadership roles in the university, volunteering in social organisations, and other things can also be of help.

Putting it together

By now, you should have a long list of things. Let's organize them in order of importance for your application:

1. Research work and it's evidence come first. These should be described in detail in your application.
2. Letters of Recommendation describing your research contributions and providing information about your class performance (ranks and not marks).
3. Relevant work experience or relevant parts of your job come a close third.
4. University GPA
5. Academic or hobby projects should have samples or documentation to support what you say you have done are very important.
6. Standardized test scores come nearly last. Yes, last. You only need to clear the minimums required by a program. Beyond that, it does little to strengthen your case.
7. The embellishments while not taking much space should be included wherever possible in your application.

Conclusion

You should have a nice list of experiences jotted down. These will help you figure out universities to apply to as well as what to put in the different parts of your application. This will vary depending on your own experiences so far. There is no one size fits all approach. 

The GRE Experience - 330/340

Part 1 - My Experience

While a 330 isn't the highest that many of you will be able to get, it certainly is enough for almost all universities and departments. The maximum that should be reasonably aimed for or worked towards is 334, which is just over the 95th percentile, and can certainly get your application through the door when it comes to the top 5 USA institutions. Beyond that, it becomes a case of diminishing returns with regards to preparation time.

My own journey started with extensive searches searching the net for everything that I could find. The first stop was the official GRE website, which listed the official ETS GRE books as the one-stop resource that everybody should look at. Specially, if they do not have the time for anything else. I must say, that after going through it, I agree with that entirely. You simply have to go through this once.

Other than that, I signed up for Magoosh's online GRE prep guide. The main thing that you get from them is their question set and the four practise tests that come with it. I spent just over one month, about 1-2 hours a day, going over their questions sets and practising with a variety of combinations to work on my weaknesses. The flexibility to focus on specific types of questions, the difficulty levels, the customization for sessions, all makes for an excellent GRE training experience.

For ESL learners, the verbal is usually the stumbling block in the way to a perfect score. My approach was to use the Magoosh vocabulary apps to practise and get through a definite number of words every day ~30 or so. To learn in context - which is what you'll need for the test and what is generally an easier approach to learning new words - I made lists of words that I didn't recognize as and when I came across them while doing Magoosh questions (and this happened a lot). After each Magoosh session and over the next few days, I went over the newly compiled word lists. This approach, for me, was much more effective than doing either themed word lists or memorizing a random bunch of words from the Magoosh apps.

(Of course, having a good grasp of English due to regular reading habits makes things much easier)

The Quant section is the easy part. Anyone doing engineering already knows everything that the quant section asks. Nonetheless, if you want to be safe and revise concepts which is always a good idea, I would recommend using the ETS book as a starting point, and exploring further into specific topics as and when you need to. Complement this with Magoosh's practise sets as I did, and you'll be on your way to an excellent score!

Finally, the last thing that you need to do is develop stamina for the full 4 hour test. The only way to get yourself ready to handle it is by doing full length practise tests in exam like conditions. The ETS guide gives you three full length tests, and Magoosh provides four. Doing them spaced throughout your prep cycle will get you ready for the marathon.

Part 2 - Takeaways

My learnings from the experience, broken down into easily digestible points:

Do a mock test as a calibration

Start your prep by going over the test format, and then doing one full test to get a basic idea of where you stand and how far you need to go. If you need to gain just 10 points, one month of prep should suffice. If you need to gain upto 20 points, then plan for three months.

Study AWA from ETS

Study the AWA samples focussing on the highest scoring ones. Look at the structure, patterns, flow, cogency, and vocabulary. Assimilate and apply in your practise test sessions. There is no need to refer to any external resource, not even Magoosh.

Do targeted practise frequently

Once you know your weaknesses, tune the practise sessions to target the specific question type that is troubling you. Focus on developing question solving techniques, and not the particular question. Watch the Magoosh videos for guidance. Question solving techniques is possibly the only area where the Magoosh videos actually help.

Do full tests regularly

Note the different word used - regularly, not frequently. Space out your practise tests over your prep duration, keeping three days or longer gaps between tests. Do not do a full test one day before the actual GRE. It's better to just rest at this point.




TL:DR I strongly recommend getting started with Magoosh GRE.

Compiling and Installing the Linux Kernel

The first few times I tried to boot from a custom kernel, I faced a lot of problems and found documentation to be a spread out in different places and also somewhat incomplete depending on the specific distribution. This guide will document the steps to be followed to get a custom kernel running, focusing on Ubuntu and Debian derivatives. The steps followed however, are almost completely, distribution neutral, and hence should be applicable for whichever distro you may be using.

Pre-requisites

I will be using the kernel tree from Kernel.org for this post. If you have a specific version, then great! Otherwise, you can clone the kernel tree using:

$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

(This requires git, but you have that installed, don't you?)

Compilation 

For the compilation process, we first need to create the configuration file. This file specifies the various properties of the kernel, including which modules to be compiled, which to be included in the image, and which to be loaded dynamically. You can, depending on your configuration, go for a modular or a monolithic kernel from here. You can either create one using the kernel utilities, or simply use the one that comes with your distro and which the current kernel is using.

$ ls /boot/*config*`uname -r` -a

Copy the config file to your kernel root directory and rename it to .config

$ cp /boot/*config*`uname -r` ./.config

Now, run make to verify the configuration file for the current distribution. You will see a number of new options that have been added into the new kernel. I would suggest simply going with the defaults on most of them, unless you know what you are doing.

$ make oldconfig

We are ready to start compiling. You simply need to run make. To make things go faster, we can make make spawn multiple jobs. Usually, 2 per core is a good number to go by. I also like to time how long it takes, hence my command is similar to:

$ time make -j$((`nproc`*2)) > ./.build-feedback

The output redirection will save all the build feedback into a file that you come back and read when compilation is over. Oh yes, it's gonna be awhile.

Installation

Assuming there weren't any errors during compile time, you are good to install your flashy new kernel. The installation process is simple and involves installing modules, copying files to the correct directories and updating your bootloader.

Installing modules is a one liner:

% make modules_install

Note at the end of the install process, you will see a version number. Copy it, or use the following command:

$ KVER=`ls /lib/modules -ht | head -n 1`

Now, we need to copy the kernel image to the /boot directory. You will find it under /arch corresponding to your machine architecture. For seeing your machine architecture, run:

$ uname -m

Or we can copy the correct image with this one liner:

% cp ./arch/`uname -m`/boot/bzImage /boot/vmlinuz-$KVER

Next, we need to copy the system map, which stores information regarding the built modules and their relative addresses for dynamic loading.

% cp System.map /boot/System.map-$KVER

Next, comes the config file.

% cp .config /boot/config-$KVER

If your distro is configured to use an initramfs, which can easily be confirmed by the presence (or absence) of initrd files in /boot, then you need to generate it using:

% update-initramfs -c -k $KVER

The last step is updating GRUB, so that the new kernel can be added to the boot list.

% update-grub2

Verification

Let's boot into the new kernel now. As the new kernel should be at the top of the GRUB boot list, you should automatically be booted into it. Once you have a usable desktop, which may or may not happen, open up a terminal, or switch to a virtual terminal, and verify your install version (should match with KVER).

$ uname -r 

Congratulations! You are now using your compiled kernel.


This process can take upto 2.5 hours the first time you attempt it, with successive attempts taking upto an hour depending on your workstation. Nonetheless, it is an exciting process and your first step transitioning towards kernel development.

Raspbmc Controller using PiTFT

Installed PiTFT in LumenEd devices

While working at LumenEd, I got the chance to work on with a lot of different peripherals and chips that go with the Raspberry Pi. One of those items was the PiTFT touchscreen.

Our goal was to develop a control application, similar to a remote, that would handle all user inputs to RaspBMC, our OS of choice. After a few weeks of tinkering, design and development, we were able to put together a simple, yet sufficient, interface, that has been deployed on our devices. This post explores the bare minimum that was needed to get things working together. To see the device in action, take a look at an
early demo video.

The software application for PiTFT is available on Github. It has been developed in Python, due to the extensive support that it has on the Pi, as well as the reduced development time that it provides (which was a priority for us during the development phase). We have used Pygame as our GUI library, for similar reasons. Also, it depends on TSLIB, for touchscreen input, and fbcon, for output to the touchscreen frame buffer.

Moving to the touchscreen itself; getting it working turned out to be a pit of a puzzle at first. Over the period of 4 days however, we were able to figure out all that was needed for it to perform reasonably well in RaspBMC. Firstly, it is necessary to calibrate the touchscreen for optimal touch performance. This is easy to do once the necessary libraries have been installed. Next, we need to load the calibration profile from within the application. This requires the use of environment variables, specifically the first four as shown below. These variables specify the input driver to use, the configuration of the hardware, and the calibration constants. For Pygame to interpret and process the input correctly, we also need to specify the SDL parameters. The parameter names are self explanatory.

	os.environ["TSLIB_TSDEVICE"] = "/dev/input/event0"
	os.environ["TSLIB_TSEVENTTYPE"] = "INPUT"
	os.environ["TSLIB_CONFFILE"] = "/etc/ts.conf"
	os.environ["TSLIB_CALIBFILE"] = "/etc/pointercal"
	os.environ["SDL_FBDEV"] = "/dev/fb1"
	os.environ["SDL_MOUSEDEV"] = os.environ["TSLIB_TSDEVICE"]
	os.environ["SDL_MOUSEDRV"] = "TSLIB"
	os.environ["SDL_VIDEODRIVER"] = "fbcon"
	os.environ["SDL_AUDIODRIVER"] = "alsa"

Another aspect of the GUI design, was the need for elements such as buttons. Pygame, surprisingly, lacks this basic GUI element. Hence, we wrote a custom class for buttons, and certain functions for some other elements as well.

Navigation Menu

Playback Control

At this point, we started to look at the performance of the application. We saw extremely high CPU usage which given the size and simplicity of the display elements and rendering, seemed counter intuitive. Nonetheless, two optimizations were incorporated and this resulted in a drop in the CPU usages to almost a eighth of the original values. One optimization was to reduce the refresh rate to the minimum possible which can be around 4-5 fps. This does not interfere with input responsiveness as the event generation is independent of the screen updation. The other optimization was to reduce the update area to only those sections that were actually changing on a per second basis. This in itself, resulted in a significant performance improvement.

 The last part of the application was forwarding the inputs to XBMC and querying specific parameters to update the touchscreen display. XBMC features an extensive JSON API accessible via the web server. With the help of a wrapper function, the API calls became short and simple. The latency for these calls was also reasonable short on the local server, making the application responsive.

	def nav_down():
	method = 'Input.Down'
	getJsonRemote(method)

Overall, the application was interesting to develop and we are very happy with its performance till date. If you would like to experiment with this application, then download version 1.0. Later versions have been extended and integrated with device-specific hardware, and hence will not be usable externally. The current versions support a camera interface, and a battery display as well.

 Lastly, if you happen to be starting with the Raspberry Pi, I would certainly encourage you to get a hold of the PiTFT and start hacking. It will make for an interesting learning experience about embedded Linux architecture. Happy hacking!

Microsmooth : Signal Smoothing Library for Arduino

During the past few months we have started work on our quadcopter platform, unimaginatively called MICAV. The quadcopter is a micro aerial vehicle with a span of less than 45 cm. The MICAV is currently being controlled remotely using the Avionic RCBX7 transmitter receiver. The device is fairly complex allowing for 7 channel control, and contains a lot of inbuilt functionality. The signals are sent to the Arduino Uno from the receiver. These are then processed, and the motor control signals are set.

As we were testing the controls, we noticed a rather odd pattern. The RPM was changing quite audibly on the motors with a high frequency. Our initial guess was that the wiring must be loose somewhere and we went over the entire circuit. Next, we tested out the motors using a control signal being generated via values sent over serial. The motors performed correctly. Nothing wrong with the motors. Phew!

This left only when avenue to explore. The RX-TX itself. We then hooked up it up with the Arduino and observed the input values being received. The results explained the problem. It was noise all along!

Noise was interfering with the control signals far too much. This necessitated the need for some signal processing to be done before sending it further. To resolve, we started exploring libraries in Arduino-verse that deal with signal processing. We found no relevant ones. The ones we did find that could work for us, were too expensive to use in terms of time and space. We then moved to studying the algorithms ourselves and implemented them. Over the course of two weeks, we programmed and tested about 5-6 algorithms with many variations of parameters.

The algorithms that we implemented are:

• Simple Moving Average
• Cumulative Moving Average
• Exponential Moving Average
• Savitzky Golay Filter
• Ramer Douglas Peucker Filter
• Kolmogorov Zurbenko Filter

Some performed surprisingly well, given the time and size constraints that were imposed.

The green signal is the result of the SMA filter applied to the input. This was one of the mediocre performing cases.

Now, given that there were no existing libraries that were suited to this task when we started to look, we felt it was best to release our code in the form of library, to help out others who may travel down this path. So, then Microsmooth came into existence!

Microsmooth hosted on Github, maintained by me and Pranav, is intended to be lightweight and fast for use in time critical Arduino-based applications. Given that none of the code is Arduino specific, it can even be used on other microcontrollers and platforms, but we make no promises. Time optimizations will eventually make us utilise microcontroller specific features, which may make the library tied down to a specific platform.

To use the library, paste the files in the source directory, and add the following include:
    #include "microsmooth.h"    

The library is still in development and we aiming to improve the overall library in many areas.

• Reduced memory utilization
• Improved algorithm performance
• Addition of new filters and greater control over existing parameters
• Switches to result in smaller footprint of the code

The library will become more stable and flexible in the months to come.

The Real Essential Questions of Every Beta

The blog post Seven Essential Meta Questions of Every Beta gets linked to prominently from every beta's meta. However, this blog post is somewhat inaccurate and actually misdirects new users. In almost every beta, for example, the site design question gets asked and undergoes a fair bit of discussion, even though a probable graduation is too far into the future for this discussion to be useful. Moreover, some of the questions are best asked after the site goes public, such as the moderator nominations, and site promotions. There are certain other issues, that can actually be of immediate use to the community, such as tag synonyms, redundant tags, chat room name, etc. but don't get sufficient attention.

Therefore, I went ahead and tried to develop a list of questions that are relevant today for betas. The most important questions, vary from site to site, and from private to public status. The answers to these will have a lasting effect on how your site operates for a very long time. The questions are divided by site status.

Private Beta

1. Are questions about [subject] on or off topic?

You should actively watch the earliest questions with an eye for quality and purpose. Ask yourself: “Is this the type of question we want on this site? Is it pushing the boundaries of on- and off-topic questions? Are we opening a can of worms?” Talk about these issues in meta, early and often. They are the key to establishing the boundaries around your site.

Remember, this is a class of questions, and not just a single question. The more specific topics that get discussed, the more meaningful the discussions will be.

For example, on Chocolate.SE, discussing:

Should dark chocolates be on-topic?

Will most likely result in flame wars, and reach no useful conclusion. However, discussing:

Should the additives used in the process of making dark chocolates be on-topic?

Will lead to more constructive discussion.

2. How should we tag questions about {subject}?

Tagging questions is an ad hoc way of organizing content. It is mostly improvised by users asking the questions but only to a point. Tag auto-completion and community editing will influence the proper use of tags for a very long time.

The type of things you should look out for: how to handle acronyms common to your subject, brand versus product-specific tags, common terminology, and the use of semantic tags to categorize specific types of questions unique to your community. Every site will have their own unique set of tag-related issues.

The best way to identify tagging problems is to watch new posts closely, and try to build tag wiki excerpts that explain what the tags are for. When tags become ambiguous, too specific (or not specific enough), or just somehow off, raise those issues in meta, and quickly. Proper tagging is very much a lead-by-example activity. The sooner you get the “community standards” for tagging ironed out, the less chance you’ll have to face the drudgery of cleaning them up later.

3. Should tag A be a synonym of tag B?

Usually, in the early stages a fair bit of redundancy gets developed as many users may suggest different variations of the same tag, or some may call the same thing by a different name. These can result in disorganization and confusion in using the tags. It is important to look for and discuss such redundancies that could become problems later on.

4. What’s the “elevator pitch” for our site?

Imagine you’ve just gotten on an elevator with a friendly stranger. You have precisely one floor to describe your community to them. What would you say? The elevator pitch is a brief sentence that describes what your site is about.

This helps in visualising what your community is about and what it is going to be. If you have trouble describing your community in one-line, then its a sign that the community needs to take a relook at its scope and purpose.

5. Whats an interesting name for the chat room?

Every site comes with its official site chat room. This is created automatically and can be reached from the Site Switcher on the top left. The chat room is the third place of your community, after main and meta. It is like the lounge where everybody can get together discuss, complain and have fun. Personalizing this space to reflect your community and what you are, is one of the small steps to take towards building an active an engaged community.

Try to get a few ideas up, discuss and vote on them. The name could be something esoteric in your field, or something that every person may understand. Whichever it may be, go ahead and start the discussion!

Public Beta

1. Who should the moderators be?

Moderators in Stack Exchange perform dual roles. Beside the normal activities of a Moderator, part of their function is to act as liaison — a role which links the Stack Exchange team with the individual communities. Discussing the criteria of a great moderator is important and picking out potential candidates is a great way to introduce outstanding contributors to your community. And we are completely open to appointing temporary Moderators when someone’s contribution makes them a standout choice for your community’s human exception handler. If your meta site does not have a post to nominate Moderators, start one now! Pro Tem appointments will begin about two weeks after the site goes public. The more guidance we receive, the more informed our choice.

2. How do we promote our site?

By now, your site should have 100+ questions, mostly excellent with expert level answers. Next comes the issue of getting the word out i.e. how to promote your site and how to reach out to the experts and peers in your industry. Meta is the perfect venue reach out and ask around about who knows whom. Ask your friends to ask their friends. The people needed to make your site a huge success are already within your reach.

Keep in mind, that this is again not one discussion, but a set of discussions that will collectively come under the tag of site-promotion. For any degree of success, it takes a bit more coordination and discipline than asking a one-shot question and expecting a final solution to simply emerge. It takes individual members to rise up and ask methodical, step-wise questions with an end-goal in mind — and follow through.

Some of the avenues to consider are:

• Encourage your community to share links to outstanding questions and answers. And if you feel you’re not producing outstanding questions and answers worthy of sharing with the world, endeavor to fix that first.
• Reach the right kind of publications and bloggers. Make sure that the key experts in every field know about the site; not just the “Martha Stewart” big names; we want to talk to the people who go to these conferences.
• Make sure evangelists from each community have the opportunity to speak before groups of experts in their fields.
• Encourage and participate in grassroots conversations in existing discussion groups, where appropriate.

You should be thinking in terms of “what is it really going to take to make this a world-class site?” Don't wait for anybody. You have to get the ball rolling. Being a voice in a crowd works for certain types of collaboration and brainstorming, but sometimes you have to take on the role of the organizational czar.

3. What should our documentation contain?

Most of the content present in the Help Center is same across the entire Network. There are some parts however, that need to be discussed and developed within the community. The most important page is the /help/on-topic page that lists broadly the scope of the site. This page acts as a guide for new members of your community and should be carefully considered and put together to accurately represent the site scope.

4. Do we really need tag [subject]?

As tags start to get better organized, there will be many problematic and extremely specific tags that may have been created initially, but do not actually serve any purpose. Such tags may be meta tags, may be redundant, or may even simply be spelling errors. Whatever the case, it is important to bring these up and discuss their need on the site. Many of these will eventually be removed, and the earlier this happens the cleaner the tags on your site stay.

Useful Links

• The 7 Essential Meta Questions of Every Beta
• A Recipe to Promote your Site
• Moderator Pro Tempore
• Your New Site: Asking the First Questions
• Redesigned Tags Page
• A Theory of Moderation
• Domain Names: The Wrong Question
• Announcer, Booster, and Publicist Badges

Originally posted on Meta Stack Overflow. Many parts taken as-is from the official blog posts.

Measuring Experimental Compliance

I came across this question on Cognitive  Sciences Stack Exchange and I thought it was pretty interesting.

How can experimental compliance (willingness of participants to participate) be measured?

I would like to have a measure for how willing and eager participants were during an experiment. I have the intuition that their eagerness to comply will profoundly alter results of psychological and even psychophysiological experiments, but I lack a good way of experimentally quantifying this. 

After giving this some thought, I felt that by applying a combination of techniques based on the learnings from obedience experiments as well as those on cognitive dissonance, it was possible to develop a technique that could reasonably measure experimental compliance.

Cognitive Dissonance at work.

I finally ended up with this:

A method that could help increase both experimental compliance as well as quantify it could be as follows: 

• Take a quiz to measure subjects' self-perceived levels of obedience

• Perform experiment normally

• Take another test to measure current self-perceived levels of obedience

Although the initial test may significantly alter levels of compliance as questions on obedience will prime subjects' to be more compliant, the initial data, if looked at with the post experiment tests results, will give an accurate picture.

Why two tests?
The first would help in measuring their attitudes towards authority and general obedience that they believe, they hold. This may be highly inaccurate as has been observed in many experiments, most famously the Milgram Experiment, where less than 10% of the subjects were able to correctly predict how far they would go.
The second one would be a measure of actual behavior during the experiment. The results of both can be interpreted as follows:

1. If the attitudes and behavior did not match, that is, subjects first rated themselves as obedient but were less than compliant during the experiment, then they would be experiencing cognitive dissonance in the post-condition test. Hence, their second results would be higher and incorrect. In fact, their actual levels of compliance would probably have been even lower than initially predicted by them.

2. If attitudes and behavior match, then the post-experiment results could either be the same, or slightly lower than the pre-experiment results depending on the individual.

• If they are the same, then the individual complied to the fullest extent possible with experimenter.

• If lesser, then the subject complied with the experimenter to the maximum extent (s)he could justify to himself.

In either of these cases, the real measures of compliance would be the results of the second test.

What to test?
The tests should contain questions which are indirect and mixed with other questions. These should be asking about general situational obedience such as when being stopped by a cop, or being approached by a formally dressed executive in a company office.
The post-condition test could be more direct and ask specifically about the test.
Lastly, this would be most effective for experiments which involve an experimenter actively conducting it, thereby creating the maximum chances of dissonance in individuals who did not fully comply. This would allow for most accurate result collection.

Of course, hard to say how effective this would be without experimenting. I would love to hear back from anybody who gave this a shot!

The Communities of Stack Exchange

Stack Exchange sites are considered by many new users as being anonymous and faceless, when they initially start participating. This happens pretty frequently on Stack Overflow where a significant number of users tend to receive a fair bit of (well-intentioned) feedback and criticism. I had, as well, received some criticism on one of my first questions on Stack Overflow. However, in the months that followed and as I started getting more involved on the site and on the Network, I started to see some pretty distinct and interesting communities and sub-communities (Why? Because I love social psychology and networks). I even participated in the formation of two new sites (Alright, the second one failed but 1 out of 2 ain't bad).  

As I got more involved, it started becoming very clear that there were different types of communities that existed and this varied from site to site. Some sites have users who know each other personally, and this tends to show on the conversations that take place. Some sites are totally professional, and this is again obvious by the type and quality of comments on main and discussion on meta. However, going through a 100+ sites one by one is not what I had in mind for this post. 

Even though the Stack Exchange Network consists of many sites each of which is so different from the rest that its hard to look at every one through the same lens, lets try to look at sites by classifying them based on age and traffic which matches up pretty well with the type of communities that are present on said sites:

SOFU (Stack Overflow, Super User, Server Fault)

Each of these were part of the original group of sites that were launched and are pretty huge compared to the rest of the Network. On these sites, there are many sub communities that exist, some of them being around tags, and others being around overall site moderation.

Communities around tags generally consist of users who are active in asking and answering questions related to the technology covered by the tag. These communities tend to consist of experts and some new users. Most new users on these sites are of the drive-by variety; they ask a few questions distributed over a long time. Hence, only the most regular users tend to become a part of such a community and once users get recognized, things get pretty social and friendly. Some tags have chat rooms associated with them where the community members hang out and socialize, the most popular ones being the Lounge C++ , Python and PHP. These communities are very hard to find and recognize, even more so, if you are an "outsider".

The second type of community that forms is around site activities and moderation. These users are almost always present on meta, in chat rooms and can be found in the review queues with high frequency. Here communities tend to form around expertise about the site and the way things work, and always consist of the Community Moderators. These users are the ones who will be at the forefront reporting bugs and asking for features, providing support and clarifying odd system behaviors. They will also be the ones most frequently closing, deleting and downvoting posts. Essentially, this community is the one which faces most of the wrath and anger (of which there is a lot) of users who do not understand the platform and they are the ones who invest the maximum time ensuring things work correctly (Some might argue too much : How do I participate in Meta Stack Overflow and not die trying? a Q&A by the moderation community on becoming a part of the community). 

The tag community (-ies) ensures content keeps being created while the moderation community ensures expected standards are being upheld. Both work together on the high volume Stack Exchange sites to make them a success. (There are overlaps between the two)

Graduated Sites 

These are all the SE 2.0 sites which have passed the beta phase and have proven that there is an audience interested in participating and maintaining it. As these sites are very specific in terms of domain, there are very rarely any distinct tag sub-communities unlike what is seen on SOFU. Hence, there is just one big user community and a moderation community. Moreover, the division between the moderation community and the user community is blurred. There is a large overlap between the two however, there are subsets of users who still belong almost exclusively to one side. These sites have much smaller communities consisting of less than 200 users where most users know everybody else within their part of the site (or in their community).

Beta Sites 

These are the sites which are in beta and may or may not stay online at the end of their beta periods. On these sites, there is just one community and almost never any sub-community (unless the site is nearing graduate site size, in which case the above description holds).

Depending on how far the site has progressed, such sites may have a community of 10 to 50 users. These sites are generally built around very specific domains and hence, there is not much room for tag communities. Also, the volume of activity is low, which means that there is no need for a specific moderation community. Therefore, these sites have one community consisting of domain experts, newbies, user moderators and Community Moderators. In my opinion (which may be biased), this type of community has the highest degree of cohesiveness compared to the rest. Everybody knows everybody else; the community itself is extremely visible, and the presence (or absence) of every member is felt and seen.



Also, on a platform that discourages socialising, there are some other patterns that can be seen. Users are rarely known by their popularity or by a few popular posts, but rather, are identified through consistent participation and visibility on the site which is an entirely different ball game compared to any social network. See the reasons mentioned in my blog post discussing Stack Exchange ideology.

Does any of this imply that SE is less social and/or unfriendly? It depends on where you are and how involved you are. As much as I would like to say an outright yes, that's not the case. However, we cannot generalize over the entire network, but we can attempt to look at some common trends that exist between similar types of communities.

User communities (discussed above) tend to be where people know each other only through technical participation and prowess and hence, these communities are more about content and technical experience rather than socialising. So, yes, domain specific communities may be less friendly and welcoming.

Coming to the moderation communities, because of the very nature of participation, the amount of socialisation is high. While SE may not have any social networking features, users who are a part of the moderation community almost certainly interact and socialise with each other through chat and/or through external platforms. So, these communities are as friendly and social as any other network. The only difference is that people tend to act a little more professionally than they would on Facebook, and hence it may appear that its all about work. Who am I trying to kid?

Beta communities are very special on this front and cannot be lumped with either of the two above. Beta communities are extremely friendly, welcoming, helpful, and (in some cases) social. The proportion of positive discussions and debates on such sites is much higher than other sites and hence these are comparatively more social.

Beta Communities are in their formative stages and there are no existing community (social) norms. Hence, every new user can shape the way they turn out. If you feel there is a need for change, go ahead and bring it about!

That brings us to the end. Finally, this is me! 

...

Coming Soon

Fitocracy : The Fitness Nation!

Official Logo

Fitocracy is a new and fast growing social network for anybody interested in staying fit. The site was created by Richard Talens and Brian Wang, and was launched in February 2011. Fitocracy is valued at 4 million USD.

Fitocracy has an extremely vibrant interface with positive feedback instilled in every action loop. The system is heavily gamified where every workout gets you points and achievements get you badges. The points system is a simple implementation of experience points. The network is extremely social with a lot of motivation and positive interactions. It is growing pretty quickly as it has over a million users who form a diverse userbase all the way from geeks to gym trainers.

One of the positive impacts of gamification is that it causes behavior change. A simple extrinsic motivational system of points and badges can make the even the most mundane or the most difficult activities seem possible and engaging, that too, on a regular basis. In the case of exercise, depending on the individual, users have many different types of motivation for doing it.  Some may be motivated by family, some by the possible health benefits, others by targets to achieve.

Points Tracker

It varies across the entire motivational spectrum. However, where Fitocracy succeeds is that it tries to capture and stimulate each of the different types of motivations through their system. By doing this, they allow users to themselves traverse through the motivational spectrum to stronger forms of motivation, or to simply increase the intensity of their current mechanisms. This over time, leads to the establishment of patterns and behaviors such as stepping out early or using the stairs in your office (points!). Fitocracy is one of the best uses of gamification that there is and it is doing so in an effective manner.

The points is finely grained and dynamic. Finely grained, as it (tries to) cover the entire spectrum of exercise types. By allowing for diverse activities, all the way from Yoga to canoeing, it allows users of diverse interests to log in their activities. It even gives users the option to explore and try out different exercises in the process. Giving users meaningful choices, is an important part of a gamified system. Moreover, there is the feature to create and save routines as per your needs which gives the much necessary control that users require. Autonomy is another basic aspect of gamification and Fitocracy provides it pretty nicely.

The Neighborhood Fitocracy Bot

Coming to the interface, it just reeks of fun. This is extremely infectious as most users also respond in a similar fashion! All the animations used, especially the Fitocracy Bot, are designed to be simple and happy.

The icons that are used all over the site are colorful, clear and seem exciting. The system feedback is not drab or like what you would expect from an application. Each message is motivating and forward-thinking. The UI buttons have not been left behind as well. Take a look at the Ok button.

Yes. You are.

Yes. Thats how cool the system is.

I have been using it for a week and I am pretty happy to say, that I have been manipulated, to get up and go out for a run every day! This is one gamified application, getting addicted to which, has lots of health benefits (unless you actually are into exercise).