[DG: User Experience] Proposal to move Sakai 3 UX code to Git and Github

[Oszkar Nagy]

As momentum is building up around Sakai 3, I am trying to find better
ways of organizing our work, and tools which makes people's life easier
who are working on anything UX related in Sakai 3. Up until now there
were only a handful of people contributing code and design, but now that
more and more developers and designers are joining in I think it's time
to put procedures, documentation and tools in place which help easy
development and contribution, especially for those who are not
necessarily well versed in coding.

In the light of this as a first step, I would like to propose a change
in our version control system, namely to move the UX code from SVN to
Git and Github. If you are wondering what is SVN, Git or version control
in general please have a look at the bottom of this page where you'll
find links to pages which will explain. For those who are familiar with
version control systems, you'll find links to comparisons with SVN,
GUIs, and other geeky stuff.

You might be wondering why change if we have a system in place, so here
are my personal reasons built up from my experiences working with
Sakai 3 UX code so far:

+ Git's distributed model in many ways fits better to the real world
model in which we are working on UX code.

+ Ability to view, download and follow the code in an easy to use
interface through Github makes it more accessible and attractive for non
technical people.

+ The Sakai 3 Kernel is using this system with success so far, and so
does many other big open source projects as you can see on Git's
homepage. Moving to the same system as the Kernel is using would mean
one need to be familiar with only one system to develop for Sakai.

+ Merging and managing patches are far more easier than SVN, which means
less work for people who review and merge/patch code, and less conflicts.

+ Good, free visual tools which are available on many platforms (see
below for examples), no need to learn the command line to work with it
necessarily.

+ No need to administer commit access, but have the ability to maintain
a master branch, with tagged snapshots for testing and releases.

+ Less fear to mess things up, commits are cheaper.

+ As the repository is stored locally on the developer's machine, there
is easy access to complete history.

+ For me personally the tree/branch concept was easier to understand
conceptually, I am primarily non-technical minded.

+ Stable and very fast, also needs less space than SVN.

+ Sakai JIRA has Git commit integration, so issue tracking can continue
as with SVN.

+ Github is free (for what we need as an open source project) and has
been stable so far for the Kernel.


Under the new system the code would be available to check out from
Github (or download as a zip or tar file), with tagged versions for
testing. I (or whoever is maintainer) would maintain a master branch and
merge in patches from everyone who is working on a branch, after
reviewing against the Sakai 3 UX Guidelines (will follow, please see below).


These are my reasons for proposing the move, aligned with other UX guys
here at Cambridge, but please let me know if anybody has any objections,
comments or advice. Otherwise I am happy to arrange the migration.


Oszkar

PS
As a next step I am aiming to put together comprehensive Sakai 3 UX
coding guidelines (HTML, CSS and JavaScript), which will follow shortly
as something to discuss and might answer previous guideline related
questions.


------------------------------------------------------------------
Git Resources:
------------------------------------------------------------------

Introduction to version control:
http://betterexplained.com/articles/a-visual-guide-to-version-control/
http://en.wikipedia.org/wiki/Revision_control

Git home page:
http://git-scm.com

Github:
http://github.com

Git - SVN Crash Course
http://git.or.cz/course/svn.html

Git for web designers:
http://www.webdesignerdepot.com/2009/03/intro-to-git-for-web-designers/

More in-depth tutorial, understanding how Git works:
http://www.eecs.harvard.edu/~cduan/technical/git/

Git - SVN comparison:
http://git.or.cz/gitwiki/GitSvnComparsion


GUIs, visual tools (Git has a built in one, but these are better):

GitX (Mac)
http://gitx.frim.nl/

QGit (Win, Source)
http://sourceforge.net/projects/qgit/

GitCola (Win, Mac, Linux)
http://cola.tuxfamily.org/index.html



_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[elicochran]

Oszkar,
Thanks for this. It makes sense to use only one source control system  
for Kernal and 3akai.

Thanks for the list of resources.

I'll add to your list that there is a Git plug-in for Aptana/Eclipse.  
I haven't used it yet but it looks like I will.

By the way, folks should consider at Aptana Studio as an IDE for front-
end development. Basically a flavor of Eclipse that favors front-end  
developers. (http://www.aptana.org/) [I just noticed that version 2.0  
of Aptana came two days ago. Many on the forums are suggesting  
sticking with version 1.5.1 until they work some bugs out.]

- Eli

On Oct 29, 2009, at 4:56 PM, Oszkar Nagy wrote:

> As momentum is building up around Sakai 3, I am trying to find better
> ways of organizing our work, and tools which makes people's life  
> easier
> who are working on anything UX related in Sakai 3. Up until now there
> were only a handful of people contributing code and design, but now  
> that
> more and more developers and designers are joining in I think it's  
> time
> to put procedures, documentation and tools in place which help easy
> development and contribution, especially for those who are not
> necessarily well versed in coding.
>
> In the light of this as a first step, I would like to propose a change
> in our version control system, namely to move the UX code from SVN to
> Git and Github. If you are wondering what is SVN, Git or version  
> control
> in general please have a look at the bottom of this page where you'll
> find links to pages which will explain. For those who are familiar  
> with
> version control systems, you'll find links to comparisons with SVN,
> GUIs, and other geeky stuff.
>
> You might be wondering why change if we have a system in place, so  
> here
> are my personal reasons built up from my experiences working with
> Sakai 3 UX code so far:
>
> + Git's distributed model in many ways fits better to the real world
> model in which we are working on UX code.
>
> + Ability to view, download and follow the code in an easy to use
> interface through Github makes it more accessible and attractive for  
> non
> technical people.
>
> + The Sakai 3 Kernel is using this system with success so far, and so
> does many other big open source projects as you can see on Git's
> homepage. Moving to the same system as the Kernel is using would mean
> one need to be familiar with only one system to develop for Sakai.
>
> + Merging and managing patches are far more easier than SVN, which  
> means
> less work for people who review and merge/patch code, and less  
> conflicts.
>
> + Good, free visual tools which are available on many platforms (see
> below for examples), no need to learn the command line to work with it
> necessarily.
>
> + No need to administer commit access, but have the ability to  
> maintain
> a master branch, with tagged snapshots for testing and releases.
>
> + Less fear to mess things up, commits are cheaper.
>
> + As the repository is stored locally on the developer's machine,  
> there
> is easy access to complete history.
>
> + For me personally the tree/branch concept was easier to understand
> conceptually, I am primarily non-technical minded.
>
> + Stable and very fast, also needs less space than SVN.
>
> + Sakai JIRA has Git commit integration, so issue tracking can  
> continue
> as with SVN.
>
> + Github is free (for what we need as an open source project) and has
> been stable so far for the Kernel.
>
>
> Under the new system the code would be available to check out from
> Github (or download as a zip or tar file), with tagged versions for
> testing. I (or whoever is maintainer) would maintain a master branch  
> and
> merge in patches from everyone who is working on a branch, after
> reviewing against the Sakai 3 UX Guidelines (will follow, please see  
> below).
>
>
> These are my reasons for proposing the move, aligned with other UX  
> guys
> here at Cambridge, but please let me know if anybody has any  
> objections,
> comments or advice. Otherwise I am happy to arrange the migration.
>
>
> Oszkar
>
> PS
> As a next step I am aiming to put together comprehensive Sakai 3 UX
> coding guidelines (HTML, CSS and JavaScript), which will follow  
> shortly
> as something to discuss and might answer previous guideline related
> questions.
>
>
> ------------------------------------------------------------------
> Git Resources:
> ------------------------------------------------------------------
>
> Introduction to version control:
> http://betterexplained.com/articles/a-visual-guide-to-version-control/
> http://en.wikipedia.org/wiki/Revision_control
>
> Git home page:
> http://git-scm.com
>
> Github:
> http://github.com
>
> Git - SVN Crash Course
> http://git.or.cz/course/svn.html
>
> Git for web designers:
> http://www.webdesignerdepot.com/2009/03/intro-to-git-for-web- 
> designers/
>
> More in-depth tutorial, understanding how Git works:
> http://www.eecs.harvard.edu/~cduan/technical/git/
>
> Git - SVN comparison:
> http://git.or.cz/gitwiki/GitSvnComparsion
>
>
> GUIs, visual tools (Git has a built in one, but these are better):
>
> GitX (Mac)
> http://gitx.frim.nl/
>
> QGit (Win, Source)
> http://sourceforge.net/projects/qgit/
>
> GitCola (Win, Mac, Linux)
> http://cola.tuxfamily.org/index.html
>
>
>
> _______________________________________________
> sakai-ux mailing list
> sakai-ux@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
>  with a subject of "unsubscribe"

. . . . . . . . . . .  .  .   .    .      .         .              .                     .

Eli Cochran
user interaction developer
ETS, UC Berkeley


_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[Oszkar Nagy]

Thanks Eli!

I have a "Resources" section in the upcoming front-end code guidelines
and best practices where Aptana Studio and the Git plugin will
definitely be listed with some other dev tools as well which proved to
be useful.

Oszkar

On 02/11/2009 17:51, Eli Cochran wrote:

> Oszkar,
> Thanks for this. It makes sense to use only one source control system
> for Kernal and 3akai.
>
> Thanks for the list of resources.
>
> I'll add to your list that there is a Git plug-in for Aptana/Eclipse. I
> haven't used it yet but it looks like I will.
>
> By the way, folks should consider at Aptana Studio as an IDE for
> front-end development. Basically a flavor of Eclipse that favors
> front-end developers. (http://www.aptana.org/) [I just noticed that
> version 2.0 of Aptana came two days ago. Many on the forums are
> suggesting sticking with version 1.5.1 until they work some bugs out.]
>
> - Eli
>
> On Oct 29, 2009, at 4:56 PM, Oszkar Nagy wrote:
>
>> As momentum is building up around Sakai 3, I am trying to find better
>> ways of organizing our work, and tools which makes people's life easier
>> who are working on anything UX related in Sakai 3. Up until now there
>> were only a handful of people contributing code and design, but now that
>> more and more developers and designers are joining in I think it's time
>> to put procedures, documentation and tools in place which help easy
>> development and contribution, especially for those who are not
>> necessarily well versed in coding.
>>
>> In the light of this as a first step, I would like to propose a change
>> in our version control system, namely to move the UX code from SVN to
>> Git and Github. If you are wondering what is SVN, Git or version control
>> in general please have a look at the bottom of this page where you'll
>> find links to pages which will explain. For those who are familiar with
>> version control systems, you'll find links to comparisons with SVN,
>> GUIs, and other geeky stuff.
>>
>> You might be wondering why change if we have a system in place, so here
>> are my personal reasons built up from my experiences working with
>> Sakai 3 UX code so far:
>>
>> + Git's distributed model in many ways fits better to the real world
>> model in which we are working on UX code.
>>
>> + Ability to view, download and follow the code in an easy to use
>> interface through Github makes it more accessible and attractive for non
>> technical people.
>>
>> + The Sakai 3 Kernel is using this system with success so far, and so
>> does many other big open source projects as you can see on Git's
>> homepage. Moving to the same system as the Kernel is using would mean
>> one need to be familiar with only one system to develop for Sakai.
>>
>> + Merging and managing patches are far more easier than SVN, which means
>> less work for people who review and merge/patch code, and less conflicts.
>>
>> + Good, free visual tools which are available on many platforms (see
>> below for examples), no need to learn the command line to work with it
>> necessarily.
>>
>> + No need to administer commit access, but have the ability to maintain
>> a master branch, with tagged snapshots for testing and releases.
>>
>> + Less fear to mess things up, commits are cheaper.
>>
>> + As the repository is stored locally on the developer's machine, there
>> is easy access to complete history.
>>
>> + For me personally the tree/branch concept was easier to understand
>> conceptually, I am primarily non-technical minded.
>>
>> + Stable and very fast, also needs less space than SVN.
>>
>> + Sakai JIRA has Git commit integration, so issue tracking can continue
>> as with SVN.
>>
>> + Github is free (for what we need as an open source project) and has
>> been stable so far for the Kernel.
>>
>>
>> Under the new system the code would be available to check out from
>> Github (or download as a zip or tar file), with tagged versions for
>> testing. I (or whoever is maintainer) would maintain a master branch and
>> merge in patches from everyone who is working on a branch, after
>> reviewing against the Sakai 3 UX Guidelines (will follow, please see
>> below).
>>
>>
>> These are my reasons for proposing the move, aligned with other UX guys
>> here at Cambridge, but please let me know if anybody has any objections,
>> comments or advice. Otherwise I am happy to arrange the migration.
>>
>>
>> Oszkar
>>
>> PS
>> As a next step I am aiming to put together comprehensive Sakai 3 UX
>> coding guidelines (HTML, CSS and JavaScript), which will follow shortly
>> as something to discuss and might answer previous guideline related
>> questions.
>>
>>
>> ------------------------------------------------------------------
>> Git Resources:
>> ------------------------------------------------------------------
>>
>> Introduction to version control:
>> http://betterexplained.com/articles/a-visual-guide-to-version-control/
>> http://en.wikipedia.org/wiki/Revision_control
>>
>> Git home page:
>> http://git-scm.com
>>
>> Github:
>> http://github.com
>>
>> Git - SVN Crash Course
>> http://git.or.cz/course/svn.html
>>
>> Git for web designers:
>> http://www.webdesignerdepot.com/2009/03/intro-to-git-for-web-designers/
>>
>> More in-depth tutorial, understanding how Git works:
>> http://www.eecs.harvard.edu/~cduan/technical/git/
>>
>> Git - SVN comparison:
>> http://git.or.cz/gitwiki/GitSvnComparsion
>>
>>
>> GUIs, visual tools (Git has a built in one, but these are better):
>>
>> GitX (Mac)
>> http://gitx.frim.nl/
>>
>> QGit (Win, Source)
>> http://sourceforge.net/projects/qgit/
>>
>> GitCola (Win, Mac, Linux)
>> http://cola.tuxfamily.org/index.html
>>
>>
>>
>> _______________________________________________
>> sakai-ux mailing list
>> sakai-ux@...
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-ux-unsubscribe@... with a subject of
>> "unsubscribe"
>
> . . . . . . . . . . . . . . . . . . .
>
> Eli Cochran
> user interaction developer
> ETS, UC Berkeley
>
>

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[clayf]

I have no direct experience with using git, but as a manager I've seen
how (apparently) little things like faster branching and merging and
less dependence on the network have improved collaborative development
in qualitative ways. At Georgia Tech we even manage our 2.x patches
with git now - svn has just become a kind of transport protocol for
synching up with sakaifoundation servers, and not something used for
management tasks on a day-to-day basis.

But I have to say I find the argument for using the same version
control as K2 less than compelling. It may be that there will be
developers who work on both ends, but I don't think we should assume
this, and over time we may in fact find this uncommon.

The key danger of git in my view is the confusion that is the flip
side of the coin of its distributed nature - understanding what the
'authoritative' codebase is, for example. I think there are ways to
manage this, but it needs to be a matter of advised practice, and it
probably shouldn't be assumed that this is just a simple swap to a new
tool for efficiency's sake. The point about trading access control and
committer lists (on the svn side) for decisions about who to merge
from and when (on the git side) is a deep one. There was a revealing
period this past Summer when Ian went on vacation for several weeks
and Carl  kept K2 work going without extra preparation or fuss, almost
before we'd realized it.

I'm also a fan of the 'social coding' and visualization tools of
github. Check out this visual history of K2:

http://github.com/thecarlhall/open-experiments/network

~Clay

On Mon, Nov 2, 2009 at 1:00 PM, Oszkar Nagy <oszkar@...> wrote:

> Thanks Eli!
>
> I have a "Resources" section in the upcoming front-end code guidelines
> and best practices where Aptana Studio and the Git plugin will
> definitely be listed with some other dev tools as well which proved to
> be useful.
>
> Oszkar
>
> On 02/11/2009 17:51, Eli Cochran wrote:
>> Oszkar,
>> Thanks for this. It makes sense to use only one source control system
>> for Kernal and 3akai.
>>
>> Thanks for the list of resources.
>>
>> I'll add to your list that there is a Git plug-in for Aptana/Eclipse. I
>> haven't used it yet but it looks like I will.
>>
>> By the way, folks should consider at Aptana Studio as an IDE for
>> front-end development. Basically a flavor of Eclipse that favors
>> front-end developers. (http://www.aptana.org/) [I just noticed that
>> version 2.0 of Aptana came two days ago. Many on the forums are
>> suggesting sticking with version 1.5.1 until they work some bugs out.]
>>
>> - Eli
>>
>> On Oct 29, 2009, at 4:56 PM, Oszkar Nagy wrote:
>>
>>> As momentum is building up around Sakai 3, I am trying to find better
>>> ways of organizing our work, and tools which makes people's life easier
>>> who are working on anything UX related in Sakai 3. Up until now there
>>> were only a handful of people contributing code and design, but now that
>>> more and more developers and designers are joining in I think it's time
>>> to put procedures, documentation and tools in place which help easy
>>> development and contribution, especially for those who are not
>>> necessarily well versed in coding.
>>>
>>> In the light of this as a first step, I would like to propose a change
>>> in our version control system, namely to move the UX code from SVN to
>>> Git and Github. If you are wondering what is SVN, Git or version control
>>> in general please have a look at the bottom of this page where you'll
>>> find links to pages which will explain. For those who are familiar with
>>> version control systems, you'll find links to comparisons with SVN,
>>> GUIs, and other geeky stuff.
>>>
>>> You might be wondering why change if we have a system in place, so here
>>> are my personal reasons built up from my experiences working with
>>> Sakai 3 UX code so far:
>>>
>>> + Git's distributed model in many ways fits better to the real world
>>> model in which we are working on UX code.
>>>
>>> + Ability to view, download and follow the code in an easy to use
>>> interface through Github makes it more accessible and attractive for non
>>> technical people.
>>>
>>> + The Sakai 3 Kernel is using this system with success so far, and so
>>> does many other big open source projects as you can see on Git's
>>> homepage. Moving to the same system as the Kernel is using would mean
>>> one need to be familiar with only one system to develop for Sakai.
>>>
>>> + Merging and managing patches are far more easier than SVN, which means
>>> less work for people who review and merge/patch code, and less conflicts.
>>>
>>> + Good, free visual tools which are available on many platforms (see
>>> below for examples), no need to learn the command line to work with it
>>> necessarily.
>>>
>>> + No need to administer commit access, but have the ability to maintain
>>> a master branch, with tagged snapshots for testing and releases.
>>>
>>> + Less fear to mess things up, commits are cheaper.
>>>
>>> + As the repository is stored locally on the developer's machine, there
>>> is easy access to complete history.
>>>
>>> + For me personally the tree/branch concept was easier to understand
>>> conceptually, I am primarily non-technical minded.
>>>
>>> + Stable and very fast, also needs less space than SVN.
>>>
>>> + Sakai JIRA has Git commit integration, so issue tracking can continue
>>> as with SVN.
>>>
>>> + Github is free (for what we need as an open source project) and has
>>> been stable so far for the Kernel.
>>>
>>>
>>> Under the new system the code would be available to check out from
>>> Github (or download as a zip or tar file), with tagged versions for
>>> testing. I (or whoever is maintainer) would maintain a master branch and
>>> merge in patches from everyone who is working on a branch, after
>>> reviewing against the Sakai 3 UX Guidelines (will follow, please see
>>> below).
>>>
>>>
>>> These are my reasons for proposing the move, aligned with other UX guys
>>> here at Cambridge, but please let me know if anybody has any objections,
>>> comments or advice. Otherwise I am happy to arrange the migration.
>>>
>>>
>>> Oszkar
>>>
>>> PS
>>> As a next step I am aiming to put together comprehensive Sakai 3 UX
>>> coding guidelines (HTML, CSS and JavaScript), which will follow shortly
>>> as something to discuss and might answer previous guideline related
>>> questions.
>>>
>>>
>>> ------------------------------------------------------------------
>>> Git Resources:
>>> ------------------------------------------------------------------
>>>
>>> Introduction to version control:
>>> http://betterexplained.com/articles/a-visual-guide-to-version-control/
>>> http://en.wikipedia.org/wiki/Revision_control
>>>
>>> Git home page:
>>> http://git-scm.com
>>>
>>> Github:
>>> http://github.com
>>>
>>> Git - SVN Crash Course
>>> http://git.or.cz/course/svn.html
>>>
>>> Git for web designers:
>>> http://www.webdesignerdepot.com/2009/03/intro-to-git-for-web-designers/
>>>
>>> More in-depth tutorial, understanding how Git works:
>>> http://www.eecs.harvard.edu/~cduan/technical/git/
>>>
>>> Git - SVN comparison:
>>> http://git.or.cz/gitwiki/GitSvnComparsion
>>>
>>>
>>> GUIs, visual tools (Git has a built in one, but these are better):
>>>
>>> GitX (Mac)
>>> http://gitx.frim.nl/
>>>
>>> QGit (Win, Source)
>>> http://sourceforge.net/projects/qgit/
>>>
>>> GitCola (Win, Mac, Linux)
>>> http://cola.tuxfamily.org/index.html
>>>
>>>
>>>
>>> _______________________________________________
>>> sakai-ux mailing list
>>> sakai-ux@...
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>>
>>> TO UNSUBSCRIBE: send email to
>>> sakai-ux-unsubscribe@... with a subject of
>>> "unsubscribe"
>>
>> . . . . . . . . . . . . . . . . . . .
>>
>> Eli Cochran
>> user interaction developer
>> ETS, UC Berkeley
>>
>>
> _______________________________________________
> sakai-ux mailing list
> sakai-ux@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"
>

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"