Merge branch 'master' of github.com:rkh/papers

Do spellchecking as well.

Conflicts:
	bithug/bithug.tex

bithug/bithug.tex

@@ -68,7 +68,7 @@ \subsubsection*{Why Social?}
 scale projects has been demonstrated by open-source like the Linux 
 Kernel\cite{kernel:www}, X.org\cite{xorg:www} or the GNU Project\cite{gnu:www}.
 In their footsteps, emerging social websites time and time again have proven how 
-losely tied bodies are capable of organizing large 
+loosely tied bodies are capable of organizing large 
 events.\cite{facebook:help}\cite{twitter:organize}\cite{facebook:organize}
 
 In this manner, we want Bithug not only to be a service to host code, but a 
@@ -87,9 +87,16 @@ \subsubsection*{The Lazy Web}
 We want Bithug to integrate with services like Twitter to let users generate 
 content about their activity. We hope that this will integrate with the 
 information flow some users might have come to like.
-\section{Project Management as a Service}
 
-DVCS/Git, Our plans, alternatives (Gitorious, GitHub FI, Gitauth)
+\section{Project Management as a Service}
+Bithug, as an alternative code hosting service, intends to focus on the people 
+behind the code. That means, common hosting features such as forking and creating 
+repositories are made possible, but the most rewarding features lie in notifying 
+the people involved in a project and giving them a platform to communicate on. As 
+people and projects are be highly diverse, we intend to offer and integrate a 
+number of web services, authentication methods and repository settings. Because 
+we intend enabling Bithug to be used in an academic context and smaller companies, 
+configuration needs to be easily personalized and highly versatile.
 
 \section{Technical Stuff}
 
@@ -141,7 +148,7 @@ \subsection{Using dynamic inheritance as means of configuration}
 it is considered extremely dangerous\footnote{Apart from maybe even seriously breaking your object space, you would have
 to clear a couple of caches used by the underlying Ruby implementation to speed up method dispatch.}, and is not used
 by Bithug. It should still be explained, as it helps to understand our implementation for not familiar with the Ruby
-method dispatch. Let us take the above example: To configure a system that would first try to authenticate against Kereberos
+method dispatch. Let us take the above example: To configure a system that would first try to authenticate against Kerberos
 and if that fails try LDAP authentication, you could change the superclass of Kerberos::User to Ldap::User which still
 is a subclass of Bithug::User. If you implement a method Bithug::User.authenticate(login, password), that should return
 true if authentication succeeds and false otherwise. Now, if Bithug::User.authenticate always returns false and both
@@ -152,7 +159,7 @@ \subsection{Using dynamic inheritance as means of configuration}
 Ruby supports a concept called Mixins\cite{apel2004using}. Mixins are one use case for Ruby modules\footnote{Others are namespacing
 and classes without instances.}. A Ruby module is defined like a Ruby class. You can define both instance and singleton
 methods\footnote{Methods defined on class side, also known as class methods.}. However, as you cannot instantiate a module,
-its instance methods are not directly usable. You can include such a module in a class. It is a common misbelieve – even among
+its instance methods are not directly usable. You can include such a module in a class. It is a common misconception – even among
 long time rubyists – that by doing so the unbound methods\footnote{Ruby term for not yet belonging to an object, thus not being
 callable.} are copied to the class and by doing so overwriting existing methods. In reality when including a module in a class,
 a new class is created, containing all the modules instance methods. That class is inserted in the inheritance chain in-between
@@ -167,7 +174,7 @@ \subsection{Using dynamic inheritance as means of configuration}
 
 The other problem is, that a module is inserted after the class in the inheritance chain, not in front of it. In the Kerberos/LDAP
 example, Bithug::User.authenticate would always return false, since the Kerberos and LDAP implementations never get called. Our
-solution to that is to have an empty class (i.e. without method definitions) called Bithug::User subclassing Bithug::AbstractUser.
+solution to that is to have an empty class (i.e. without method definitions) called Bithug::User sub classing Bithug::AbstractUser.
 All our common logic is placed inside AbstractUser. Now, if we include a module in Bithug::User, it is inserted in front of AbstractUser
 in the inheritance chain, thus getting called.