User:ADalal

(Difference between revisions)
Jump to: navigation, search
Line 10: Line 10:
 
'''Website:''' http://cs.carleton.edu/faculty/adalal <br />
 
'''Website:''' http://cs.carleton.edu/faculty/adalal <br />
 
'''Blog:''' http://acdalal.wordpress.com <br />
 
'''Blog:''' http://acdalal.wordpress.com <br />
 +
 +
== Part A Activities ==
 +
 +
=== Project Anatomy Activity notes ===
 +
Sugar labs project
 +
* The most natural roles for my students would probably be developer, designer (for HCI classes and/or capstone projects), and content writer (technical content).
 +
* It looks like you submit bugs through the repository, and then I assume they are auto-added to the bugtracker. I found it interesting that most of the bugs I clicked on when poking around the bugtracker were many years old --- kind of a scary thought! I wish there was a way to sort by date added so it's easier to see the newer bugs. Also, the process for submitting a bug does not seem to be very user-friendly --- the issues page doesn't provide a lot of info on what data the developers would like to know, and the "how to submit a bug report" guide was long, rambly, and at times condescending.
 +
* Last commit was 3/10/2014 (?!) according to the Activity page
 +
* The roadmap is updated at the beginning of each release cycle
 +
 +
Sahana Eden project
 +
* There are definitely distinct roles in this project. This project also had a much different "feel" than Sugar Labs. Whereas the Sugar Labs page seemed a bit more hierarchical ("contact this person if you want to contribute as an X"), these pages seem more to invite the person to jump in and start playing around with things. I also found the information on submitting bugs under the Testing page to be WAY more accessible and useful than the one for the Sugar Labs project. In summary, Sugar Labs felt like you had to join an exclusive club to contribute, while Sahana seems more open.
 +
* The bugtracking page is way better organized and easier to follow than the one for Sugar Labs. You can actually see dates and things are better categorized.
 +
* Roadmap: again, the info here seems well-organized, with succinct summaries of deliverables or work-in-progress. Seems like no recent activity, though, so it's unclear when/how often these are updated.
 +
 +
'''Summary''': It was interesting to see how differently each project presented itself. It's made me think that one of the important factors in deciding on a project for a class should be how welcoming the community seems. I could see how, for instance, someone who maybe is not as sure of themselves as a CS major could feel overwhelmed or put off by the way a project is presented, and how this could actually turn someone ''off'' from CS, rather than attracting them ''to'' CS.

Revision as of 21:05, 4 October 2016

Bio

Amy Csizmar Dalal is an Associate Professor of Computer Science at Carleton College in Northfield, MN. She teaches courses at the introductory level, as well as Data Structures, Software Design, Computer Organization and Architecture, Human-Computer Interaction, Computer Networks, and Computer Security. She also regularly supervises senior capstone projects and is very involved in integrating academic civic engagement into her courses. Her research interests include quality of service/quality of experience of Internet applications; self-healing networks; human-computer interaction; streaming media; network measurement; and performance analysis of computer and communication networks.

In her spare time, Amy is an avid runner and voracious reader and likes to spend as much time as possible outdoors.

Email: adalal@carleton.edu
Twitter: @drcsiz
Website: http://cs.carleton.edu/faculty/adalal
Blog: http://acdalal.wordpress.com

Part A Activities

Project Anatomy Activity notes

Sugar labs project

  • The most natural roles for my students would probably be developer, designer (for HCI classes and/or capstone projects), and content writer (technical content).
  • It looks like you submit bugs through the repository, and then I assume they are auto-added to the bugtracker. I found it interesting that most of the bugs I clicked on when poking around the bugtracker were many years old --- kind of a scary thought! I wish there was a way to sort by date added so it's easier to see the newer bugs. Also, the process for submitting a bug does not seem to be very user-friendly --- the issues page doesn't provide a lot of info on what data the developers would like to know, and the "how to submit a bug report" guide was long, rambly, and at times condescending.
  • Last commit was 3/10/2014 (?!) according to the Activity page
  • The roadmap is updated at the beginning of each release cycle

Sahana Eden project

  • There are definitely distinct roles in this project. This project also had a much different "feel" than Sugar Labs. Whereas the Sugar Labs page seemed a bit more hierarchical ("contact this person if you want to contribute as an X"), these pages seem more to invite the person to jump in and start playing around with things. I also found the information on submitting bugs under the Testing page to be WAY more accessible and useful than the one for the Sugar Labs project. In summary, Sugar Labs felt like you had to join an exclusive club to contribute, while Sahana seems more open.
  • The bugtracking page is way better organized and easier to follow than the one for Sugar Labs. You can actually see dates and things are better categorized.
  • Roadmap: again, the info here seems well-organized, with succinct summaries of deliverables or work-in-progress. Seems like no recent activity, though, so it's unclear when/how often these are updated.

Summary: It was interesting to see how differently each project presented itself. It's made me think that one of the important factors in deciding on a project for a class should be how welcoming the community seems. I could see how, for instance, someone who maybe is not as sure of themselves as a CS major could feel overwhelmed or put off by the way a project is presented, and how this could actually turn someone off from CS, rather than attracting them to CS.

Personal tools
Namespaces
Variants
Actions
Events
Learning Resources
HFOSS Projects
Evaluation
Navigation
Toolbox