http://www.foss2serve.org/api.php?action=feedcontributions&user=Cmurphy&feedformat=atomFoss2Serve - User contributions [en]2024-03-28T18:11:36ZUser contributionsMediaWiki 1.18.1http://www.foss2serve.org/index.php/PublicationsPublications2019-09-25T02:18:54Z<p>Cmurphy: /* Related Efforts */</p>
<hr />
<div><br />
This page contains references to publications and events that are related to the effort to help students contribute to HFOSS.<br />
<br />
== Papers ==<br />
Journals<br />
* Hislop, Gregory W. and Jackson, Stoney and Ellis, Heidi J.C. (2015). FOSS Artifacts for Evaluating Students on Team Projects. Proceedings of the 16th Annual Conference on Information Technology Education. New York, NY, USA.<br />
<br />
* Hislop, Gregory W. and Ellis, Heidi J.C. (2015). Practical Experiences for IT Students in Humanitarian Free and Open Source Software Projects. Proceedings of the 16th Annual Conference on Information Technology Education. New York, NY, USA.<br />
<br />
* Heidi J. C. Ellis, Gregory W. Hislop, Stoney Jackson, and Lori Postner. 2015. Team Project Experiences in Humanitarian Free and Open Source Software (HFOSS). Trans. Comput. Educ. 15, 4, Article 18 (December 2015), 23 pages. DOI=http://dx.doi.org/10.1145/2684812 <br />
<br />
* Gregory W. Hislop, Heidi J.C. Ellis, S. Monisha Pulimood, Becka Morgan, Suzanne Mello-Stark, Ben Coleman, and Cam Macdonell. 2015. A Multi-Institutional Study of Learning via Student Involvement in Humanitarian Free and Open Source Software Projects. In Proceedings of the eleventh annual International Conference on International Computing Education Research (ICER '15). ACM, New York, NY, USA, 199-206. DOI=http://dx.doi.org/10.1145<br />
<br />
* Ellis, H. J. C., & Hislop, G. W., & Pulimood, S. M., & Morgan, B., & Coleman, B. (2015, June), Software Engineering Learning in HFOSS: A Multi-Institutional Study Paper presented at 2015 ASEE Annual Conference and Exposition, Seattle, Washington. DOI=http://dx.doi.org/10.18260/p.24716<br />
<br />
* Jackson, S., Ellis, H. (2015). Supporting HFOSS using Scrum in a Capstone Course. Abstract and presentation for SIGCAS Symposium on Computing for Social Good. SIGCAS Comput. Soc. 45, 2 (July 2015). <br />
<br />
* Postner, L., Jackson, S., Ellis, H., Hislop, G., Burdge, D., and Goggins, S. (2015). Using Humanitarian Free and Open Source Software (HFOSS) to Introduce Computing for the Social Good. Abstract and presentation for SIGCAS Symposium on Computing for Social Good. SIGCAS Comput. Soc. 45, 2 (July 2015), 3535.<br />
<br />
* Heidi J.C. Ellis, Stoney Jackson, Darci Burdge, Lori Postner, Gregory W. Hislop, and Joanie Diggs. 2014. Learning within a professional environment: shared ownership of an HFOSS project. In Proceedings of the 15th Annual Conference on Information technology education (SIGITE '14). ACM, New York, NY, USA, 95-100. DOI=http://dx.doi.org/10.1145/2656450.2656468 <br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Purcell, M.; Chua, M.; Dziallas, S., "Towards a model of faculty development for FOSS in education," in Software Engineering Education and Training (CSEE&T), 2013 IEEE 26th Conference on , vol., no., pp.269-273, 19-21 May 2013. DOI=http://dx.doi.org/10.1109/CSEET.2013.6595259<br />
<br />
* Ellis, H. J., & Hislop, G. W., & Rodriguez, J. S., & Morelli, R. (2012, June), Student Software Engineering Learning via Participation in Humanitarian FOSS Projects Paper presented at 2012 ASEE Annual Conference, San Antonio, Texas. https://peer.asee.org/21949<br />
<br />
* Heidi J.C. Ellis, Michelle Purcell, and Gregory W. Hislop. 2012. An approach for evaluating FOSS projects for student participation. In Proceedings of the 43rd ACM technical symposium on Computer Science Education (SIGCSE '12). ACM, New York, NY, USA, 415-420. DOI=http://dx.doi.org/10.1145/2157136.2157260<br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Chua, M.; Dziallas, S., "How to involve students in FOSS projects," in Frontiers in Education Conference (FIE), 2011 , vol., no., pp.T1H-1-T1H-6, 12-15 Oct. 2011. DOI=http://dx.doi.org/10.1109/FIE.2011.6142994<br />
<br />
* Ralph Morelli, Allen Tucker, Norman Danner, Trishan R. De Lanerolle, Heidi J. C. Ellis, Ozgur Izmirli, Danny Krizanc, and Gary Parker. 2009. Revitalizing computing education through free and open source software for humanity. Commun. ACM 52, 8 (August 2009), 67-75. DOI=http://doi.acm.org/10.1145/1536616.1536635 <br />
<br />
* Gregory W. Hislop, Heidi J.C. Ellis, and Ralph A. Morelli. 2009. Evaluating student experiences in developing software for humanity. SIGCSE Bull. 41, 3 (July 2009), 263-267. DOI=http://dx.doi.org/10.1145/1595496.1562959 <br />
<br />
* Ellis, H.J.C.; Morelli, R.A.; Hislop, G.W., "Work in progress - challenges to educating students within the Community of Open Source Software for Humanity," in Frontiers in Education Conference, 2008. FIE 2008. 38th Annual , vol., no., pp.S3H-7-S3H-8, 22-25 Oct. 2008. DOI=http://dx.doi.org/10.1109/FIE.2008.4720515<br />
<br />
* Ellis, H.; Morelli, R.A.; Hislop, G.W., "Support for Educating Software Engineers Through Humanitarian Open Source Projects," in Software Engineering Education and Training Workshop, 2008. CSEETW '08. 21st IEEE-CS Conference on , vol., no., pp.1-4, 14-17 April 2008. DOI=http://dx.doi.org/10.1109/CSEETW.2008.5<br />
<br />
* Ellis, H.J.C.; Hislop, G.W., "Fostering the Community of Software Engineering Educators," in Software Engineering Education and Training, 2008. CSEET '08. IEEE 21st Conference on , vol., no., pp.233-237, 14-17 April 2008. DOI=http://dx.doi.org/10.1109/CSEET.2008.18<br />
<br />
* Ellis, H.J.C.; Morelli, R.A.; de Lanerolle, T.R.; Hislop, G.W., "Holistic Software Engineering Education Based on a Humanitarian Open Source Project," in Software Engineering Education & Training, 2007. CSEET '07. 20th Conference on , vol., no., pp.327-335, 3-5 July 2007. DOI=http://dx.doi.org/10.1109/CSEET.2007.26<br />
<br />
* Morelli, R.A., Ellis, H.J.C., de Lanerolle, T., Damon, J., and Walti, C., “Can Student-Written Software Help Sustain Humanitarian FOSS?”, The 4th International Conference on Information Systems for Crisis Response and Management, Delft, the Netherlands, May 2007, pp. 41-44. PDF:http://www.cs.trincoll.edu/~ram/ram/MorelliEtAl_ISCRAM07.pdf<br />
<br />
* Heidi J. C. Ellis, Ralph A. Morelli, Trishan R. de Lanerolle, Jonathan Damon, and Jonathan Raye. 2007. Can humanitarian open-source software development draw new students to CS?. SIGCSE Bull. 39, 1 (March 2007), 551-555. DOI=http://dx.doi.org/10.1145/1227504.1227495<br />
<br />
<br />
Conferences<br />
* Hislop, Gregory W. and Ellis, Heidi J. C. (2016). Building the Student Pipeline to Open Source Communities using HFOSS. 2016 Red Hat Summit.<br />
<br />
* Ellis, Heidi J. C. and Hislop, Gregory W. (2016). Want Students Ready to Contribute? Let’s Discuss What They Should Know!. 2016 OSCON Everything Open Conference.<br />
<br />
== Panels and Posters ==<br />
<br />
* Weiss, Stewart and Klukowska, Joanna and Burge, Darci (2017). Injecting Open Source Content Into CS2/Data Structures Courses (poster). 22nd Annual Consortium For Computing Sciences in Colleges, Northeastern Conference. <br />
<br />
* Murphy, Christian and Buffardi, Kevin and Dehlinger, Josh and Lambert, Lynn, and Veilleux, Nanette (2017). Community Engagement with Free and Open Source Software (panel). 48th ACM SIGCSE Technical Symposium on Computer Science Education.<br />
<br />
* Ellis, Heidi J. C. and Hislop, Gregory W. and Burdge, Darci and Postner, Lori and Jackson, Stoney (2016). Learning via Student Participation in Humanitarian Free and Open Source Software Projects. NSF/AAAS conference on Envisioning the Future of Undergraduate STEM Education: Research and Practice.<br />
<br />
* Ellis, Heidi J. C. and Hislop, Gregory W. and Burdge, Darci and Postner, Lori and Jackson, Stoney and Kussmaul, Clif (2016). OpenPath – Improving Student Pathways to Computing Professions via Humanitarian Free and Open Source Software. NSF/AAAS conference on Envisioning the Future of Undergraduate STEM Education: Research and Practice.<br />
<br />
* Jackson, Stoney and Ellis, Heidi J. C. and Hislop, Gregory W. and Postner, Lori and Jackson, Stoney (2015). Team Project Experiences in Humanitarian Free and Open Source Software (HFOSS): Faculty Poster Abstract. J. Comput. Sci. Coll. USA.<br />
<br />
* Alkoby, Karen and Burdge, Darci and Morgan, Becka and Ordonez, Patti and Likins, Gina (2015). Humanitarian Free and Open Source Software: Motivating the Underrepresented. Grace Hopper Celebration of Women in Computing 2015.<br />
<br />
* Pulimood, S. M., Hislop, G.W., and Ellis, H.J.C., “A Multi-Institutional Study of Self-Perceived Learning via Student Involvement in HFOSS Projects,” Poster. CCSC-EA, Atlantic City NJ, Oct. 2015.<br />
<br />
* Gregory W. Hislop and Heidi J.C. Ellis. 2015. Practical Experiences for IT Students in Humanitarian Free and Open Source Software Projects. In Proceedings of the 16th Annual Conference on Information Technology Education (SIGITE '15). ACM, New York, NY, USA, 99-99. DOI=http://dx.doi.org/10.1145/2808006.2808042 <br />
<br />
* Gregory W. Hislop, Stoney Jackson, and Heidi J.C. Ellis. 2015. FOSS Artifacts for Evaluating Students on Team Projects. In Proceedings of the 16th Annual Conference on Information Technology Education (SIGITE '15). ACM, New York, NY, USA, 57-57. DOI=http://dx.doi.org/10.1145/2808006.2808009 <br />
<br />
* Jackson, S., Ellis H.J.C., Hislop, G.W., and Postner, L., “Team project experiences in humanitarian free and open source software (HFOSS)”: faculty poster abstract. J. Comput. Sci. Coll (CCSCNE '15). 30, 6 (June 2015), 156-157.<br />
<br />
* Ellis, H.J.C., Burdge, D., Morgan, R., Ordóñez, P. and Alkoby, K., “Using Humanitarian Free and Open Source Software (HFOSS) to Attract the Underrepresented to Computer Science,” 2015 ACM Richard Tapia Celebration of Diversity in Computing, Boston, MA. Panel.<br />
<br />
* Heidi J.C. Ellis and Gregory W. Hislop. 2014. Structuring software engineering learning within open source software participation. In Proceedings of the 2014 conference on Innovation & technology in computer science education (ITiCSE '14). ACM, New York, NY, USA, 326-326. DOI=http://dx.doi.org/10.1145/2591708.2602681 <br />
<br />
* Heidi J.C. Ellis, Gregory W. Hislop, and Joanmarie Diggs. 2013. Developing HFOSS projects using integrated teams across levels and institutions. In Proceedings of the 18th ACM conference on Innovation and technology in computer science education (ITiCSE '13). ACM, New York, NY, USA, 349-349. DOI=http://dx.doi.org/10.1145/2462476.2465613 <br />
<br />
* Heidi J.C. Ellis, Stoney Jackson, Darci Burdge, Lori Postner, Gregory W. Hislop, and Joanmarie Diggs. 2014. Learning within a professional environment: shared ownership of an HFOSS project. In Proceedings of the 2014 conference on Innovation & technology in computer science education (ITiCSE '14). ACM, New York, NY, USA, 337-337. DOI=http://dx.doi.org/10.1145/2591708.2602660 <br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Purcell, M.; Chua, M.; Dziallas, S., "Towards a model of faculty development for FOSS in education," in Software Engineering Education and Training (CSEE&T), 2013 IEEE 26th Conference on , vol., no., pp.269-273, 19-21 May 2013. DOI=http://dx.doi.org/10.1109/CSEET.2013.6595259<br />
<br />
* Purcell, M., Ellis, H.J.C., and Hislop, G.W. (2013). An Approach for Evaluating Open Source Projects for Student Participation. Poster at CCSC NE.<br />
<br />
* Ellis, H.J.C., and Hislop, G.W. (2013). Community-Based Student Learning via Participation in Humanitarian FOSS Projects. Poster at CCSC NE.<br />
<br />
*Ellis, H.J.C.,, Hislop, G.W., and Morelli, R.A., “SoftHum: Student Participation in the Community of Open Source Software for Humanity,” Poster, 2013 NSF/AASE Conference for Principle Investigators of the Transforming Undergraduate Education STEM program, January 23-25, 2013 Washington, D.C. <br />
<br />
* Ellis, H.J.C.,, Hislop, G.W., and Morelli, R.A., “HumIT: Student IT Services to Support Open Source Software for Humanity,” Poster, 2013 NSF/AASE Conference for Principle Investigators of the Transforming Undergraduate Education STEM program, January 23-25, 2013 Washington, D.C. <br />
<br />
* Clif Kussmaul, Heidi J.C. Ellis, and Gregory W. Hislop. 2012. 50 ways to be a FOSSer: simple ways to involve students & faculty (abstract only). In Proceedings of the 43rd ACM technical symposium on Computer Science Education (SIGCSE '12). ACM, New York, NY, USA, 671-671. DOI=http://dx.doi.org/10.1145/2157136.2157393 <br />
<br />
* Heidi J.C. Ellis and Gregory W. Hislop. 2011. Student IT services to support open source software for humanity. In Proceedings of the 2011 conference on Information technology education (SIGITE '11). ACM, New York, NY, USA, 307-308. DOI=http://dx.doi.org/10.1145/2047594.2047676 <br />
<br />
* Heidi J.C. Ellis, Gregory W. Hislop, and Ralph A. Morelli. 2011. A comparison of software engineering knowledge gained from student participation in humanitarian foss projects. In Proceedings of the 16th annual joint conference on Innovation and technology in computer science education (ITiCSE '11). ACM, New York, NY, USA, 360-360. DOI=http://dx.doi.org/10.1145/1999747.1999874 <br />
<br />
* Heidi J.C. Ellis and Gregory W. Hislop. 2011. Courseware: student learning via FOSS field trips. In Proceedings of the 16th annual joint conference on Innovation and technology in computer science education (ITiCSE '11). ACM, New York, NY, USA, 329-329. DOI=http://dx.doi.org/10.1145/1999747.1999840 <br />
<br />
* Heidi J.C. Ellis, Mel Chua, Matthew C. Jadud, and Gregory W. Hislop. 2011. Learning through open source participation. In Proceedings of the 42nd ACM technical symposium on Computer science education (SIGCSE '11). ACM, New York, NY, USA, 83-84. DOI=http://dx.doi.org/10.1145/1953163.1953191<br />
<br />
* Ellis, H.J.C., Hislop, G.W., and Morelli, R.A., “SoftHum: Student Participation in the Community of Open Source Software for Humanity,” Poster, NSF 2011 CCLI-TUES PIs Conference, Washington, DC, Jan. 26-28, 2011.<br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Chua, M.; Kussmaul, Clif; Burke, Matthew M., "Panel — Teaching students to participate in Open Source Software projects," in Frontiers in Education Conference (FIE), 2010 IEEE , vol., no., pp.F2B-1-F2B-2, 27-30 Oct. 2010. DOI=http://dx.doi.org/10.1109/FIE.2010.5673437<br />
<br />
* Bonhomme-Biais, A., Ellis, H.J.C., Lockwood, J., and Raschid, L., “Open Source for Good” Panel, Grace Hopper Celebration of Women in Computing, Washington, DC, Oct. 2010<br />
<br />
* Hislop, G.W., Ellis, H.J.C., DeKoenigsburg, G., and Jazayeri, D., “Student Participation in OSS Projects,” The 6th International Conference on Open Source Systems, Notre Dame, IN, June, 2010.<br />
<br />
* Heidi J. C. Ellis, Gregory W. Hislop, Ralph Morelli, and Norman Danner. 2010. Instructional aspects of student participation in humanitarian Free and Open Source Software: panel discussion. J. Comput. Sci. Coll. 25, 6 (June 2010), 152-154. <br />
<br />
* Ellis, H.J.C., Hislop, G.W., and Ibanez, L., “Opportunities for Students to Contribute to FOSS Projects,” O’Reilly Open Source Convention (OSCON), Portland, OR, July 19-23, 2010. [[http://cdn.oreillystatic.com/en/assets/1/event/45/Opportunities%20for%20Students%20to%20Contribute%20to%20FOSS%20Projects%20Presentation.odp .ODP]]<br />
<br />
== Related Efforts ==<br />
<br />
* Roca, Alberto and Robinson, Rosario and Murphy, Christian (2019). Learn About Open Source Software (Birds of a Feather). 2019 ACM Richard Tapia Celebration of Diversity in Computing.<br />
<br />
* Roca, Alberto and Robinson, Rosario and Murphy, Christian (2018). Learn About Open Source Software (Birds of a Feather). 2018 ACM Richard Tapia Celebration of Diversity in Computing.<br />
<br />
* Murphy, Christian and Weng, Judy and Pearce, Jan and Veilleux, Nanette (2017). Addressing Diversity &amp; Inclusion Issues in Computer Science through Contributions to Free and Open Source Software (Birds of a Feather). 2017 ACM Richard Tapia Celebration of Diversity in Computing.<br />
<br />
* Ellis, Heidi J.C. and Jackson, Stoney and Hislop, Gregory W. and Pulimood, S. Monisha and Likins, Gina (2016). Preparing to Teach Humanitarian Open Source (Abstract Only). Proceedings of the 47th ACM Technical Symposium on Computing Science Education. New York, NY, USA. Birds of a Feather Session (BoF) at SIGCSE Symposium.<br />
<br />
* Rebelsky, Sam A. and Morgan, Becka and Pulimood, S. Monisha and Postner, Lori and Hislop, Gregory W. (2015). Incorporating Humanitarian Free and Open Source Software in CS Classrooms. Grace Hopper Celebration of Women in Computing 2015. Birds of a Feather Session (BoF).<br />
<br />
* Postner, L., Jackson, S., Coleman, B., MelloStark, S., Rebelsky, S. (2015). Student Contributions to Humanitarian Free and Open Source Software (HFOSS). Birds of a Feather Session and abstract at SIGCSE 2015 Symposium.<br />
<br />
* Gregory W. Hislop, Heidi J.C. Ellis, Darci Burdge, Sean Goggins, Lori Postner, and Stoney Jackson. 2013. Encouraging faculty & student involvement in humanitarian free and open source software (HFOSS)(abstract only). In Proceeding of the 44th ACM technical symposium on Computer science education (SIGCSE '13). ACM, New York, NY, USA, 751-751. DOI=http://dx.doi.org/10.1145/2445196.2445481 <br />
<br />
* Wurst, K., Postner, L., and Jackson, S. (2014). Teaching Open Source (Software). Birds of a Feather Session (BoF) at SIGCSE Symposium.<br />
<br />
== Workshops ==<br />
* Burdge, Darci and Jackson, Stoney (2016). Git 101: Foundations for a Common Workflow to Contribute to HFOSS: Tutorial Presentation. J. Comput. Sci. Coll. 31 (6), 18-20. <br />
<br />
* Burdge, Darci and Jackson, Stoney (2016). Git 102: A Common Workflow to Contribute to HFOSS: Tutorial Presentation. J. Comput. Sci. Coll. 31 (6), 34-36.<br />
<br />
* Ellis, H.J.C., Jackson, S., Hislop, G.W., Postner, L., and Burdge, D. (2014). Getting Started in Open Source - A Tour of a Real Project. Workshop at CCSC NE.<br />
<br />
* Hislop, G.W., Burdge, D., Postner, L., and Ellis H.J.C (2013). Preparing for Student Participation in HFOSS Projects - FOSS Tools and Techniques. Workshop at CCSC E.<br />
<br />
* Ellis, H.J.C., and Hislop, G.W. (2013). Project Selection for Student Participation in Humanitarian FOSS. Workshop at the 26th Annual Conference on Software Engineering Education and Training (SIGITE).<br />
<br />
* Ellis, H.J.C., Hislop, G.W., and Purcell, M. (2013). Project Selection for Student Involvement in Humanitarian FOSS. Workshop at 26th Annual Conference on Software Engineering Education and Training (CSEET). San Francisco.<br />
<br />
* Ellis, H.J.C., Hislop, G.W., Purcell, M., and Postner, L. (2013). Project Selection for Student Participation in Humanitarian FOSS. Workshop at CCSC NE.<br />
<br />
* Ellis, H.J.C., and Hislop, G.W., “Project Selection for Student Participation in Humanitarian FOSS,” 26th Annual Conference on Software Engineering Education and Training, San Francisco, May. 2013<br />
<br />
* Ellis, H.J.C., and Hislop, G.W., “Student Participation in Humanitarian Open Source Software (HFOSS),” Lightening Talk, 2011 International Computing Education Research Workshop, Providence, RI, August, 2011. <br />
<br />
* Morelli, R.A., Danner, N., Iyengar, J., de Lanerolle, T. R., and Ellis, H.J.C., “Teaching and Building Humanitarian Open Source Software,” SIGCSE 2008, Technical Symposium on Computer Science Education, Portland OR, Mar. 2008.<br />
<br />
* Morelli, R.A., Danner, N., Iyengar, J., de Lanerolle, T. R., and Ellis, H.J.C., “Teaching and Building Humanitarian Open Source Software,” SIGCSE 2008, Technical Symposium on Computer Science Education, Portland OR, Mar. 2008.<br />
<br />
<br />
[[Category:Reference]]</div>Cmurphyhttp://www.foss2serve.org/index.php/PublicationsPublications2018-09-22T12:26:42Z<p>Cmurphy: /* Related Efforts */</p>
<hr />
<div><br />
This page contains references to publications and events that are related to the effort to help students contribute to HFOSS.<br />
<br />
== Papers ==<br />
Journals<br />
* Hislop, Gregory W. and Jackson, Stoney and Ellis, Heidi J.C. (2015). FOSS Artifacts for Evaluating Students on Team Projects. Proceedings of the 16th Annual Conference on Information Technology Education. New York, NY, USA.<br />
<br />
* Hislop, Gregory W. and Ellis, Heidi J.C. (2015). Practical Experiences for IT Students in Humanitarian Free and Open Source Software Projects. Proceedings of the 16th Annual Conference on Information Technology Education. New York, NY, USA.<br />
<br />
* Heidi J. C. Ellis, Gregory W. Hislop, Stoney Jackson, and Lori Postner. 2015. Team Project Experiences in Humanitarian Free and Open Source Software (HFOSS). Trans. Comput. Educ. 15, 4, Article 18 (December 2015), 23 pages. DOI=http://dx.doi.org/10.1145/2684812 <br />
<br />
* Gregory W. Hislop, Heidi J.C. Ellis, S. Monisha Pulimood, Becka Morgan, Suzanne Mello-Stark, Ben Coleman, and Cam Macdonell. 2015. A Multi-Institutional Study of Learning via Student Involvement in Humanitarian Free and Open Source Software Projects. In Proceedings of the eleventh annual International Conference on International Computing Education Research (ICER '15). ACM, New York, NY, USA, 199-206. DOI=http://dx.doi.org/10.1145<br />
<br />
* Ellis, H. J. C., & Hislop, G. W., & Pulimood, S. M., & Morgan, B., & Coleman, B. (2015, June), Software Engineering Learning in HFOSS: A Multi-Institutional Study Paper presented at 2015 ASEE Annual Conference and Exposition, Seattle, Washington. DOI=http://dx.doi.org/10.18260/p.24716<br />
<br />
* Jackson, S., Ellis, H. (2015). Supporting HFOSS using Scrum in a Capstone Course. Abstract and presentation for SIGCAS Symposium on Computing for Social Good. SIGCAS Comput. Soc. 45, 2 (July 2015). <br />
<br />
* Postner, L., Jackson, S., Ellis, H., Hislop, G., Burdge, D., and Goggins, S. (2015). Using Humanitarian Free and Open Source Software (HFOSS) to Introduce Computing for the Social Good. Abstract and presentation for SIGCAS Symposium on Computing for Social Good. SIGCAS Comput. Soc. 45, 2 (July 2015), 3535.<br />
<br />
* Heidi J.C. Ellis, Stoney Jackson, Darci Burdge, Lori Postner, Gregory W. Hislop, and Joanie Diggs. 2014. Learning within a professional environment: shared ownership of an HFOSS project. In Proceedings of the 15th Annual Conference on Information technology education (SIGITE '14). ACM, New York, NY, USA, 95-100. DOI=http://dx.doi.org/10.1145/2656450.2656468 <br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Purcell, M.; Chua, M.; Dziallas, S., "Towards a model of faculty development for FOSS in education," in Software Engineering Education and Training (CSEE&T), 2013 IEEE 26th Conference on , vol., no., pp.269-273, 19-21 May 2013. DOI=http://dx.doi.org/10.1109/CSEET.2013.6595259<br />
<br />
* Ellis, H. J., & Hislop, G. W., & Rodriguez, J. S., & Morelli, R. (2012, June), Student Software Engineering Learning via Participation in Humanitarian FOSS Projects Paper presented at 2012 ASEE Annual Conference, San Antonio, Texas. https://peer.asee.org/21949<br />
<br />
* Heidi J.C. Ellis, Michelle Purcell, and Gregory W. Hislop. 2012. An approach for evaluating FOSS projects for student participation. In Proceedings of the 43rd ACM technical symposium on Computer Science Education (SIGCSE '12). ACM, New York, NY, USA, 415-420. DOI=http://dx.doi.org/10.1145/2157136.2157260<br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Chua, M.; Dziallas, S., "How to involve students in FOSS projects," in Frontiers in Education Conference (FIE), 2011 , vol., no., pp.T1H-1-T1H-6, 12-15 Oct. 2011. DOI=http://dx.doi.org/10.1109/FIE.2011.6142994<br />
<br />
* Ralph Morelli, Allen Tucker, Norman Danner, Trishan R. De Lanerolle, Heidi J. C. Ellis, Ozgur Izmirli, Danny Krizanc, and Gary Parker. 2009. Revitalizing computing education through free and open source software for humanity. Commun. ACM 52, 8 (August 2009), 67-75. DOI=http://doi.acm.org/10.1145/1536616.1536635 <br />
<br />
* Gregory W. Hislop, Heidi J.C. Ellis, and Ralph A. Morelli. 2009. Evaluating student experiences in developing software for humanity. SIGCSE Bull. 41, 3 (July 2009), 263-267. DOI=http://dx.doi.org/10.1145/1595496.1562959 <br />
<br />
* Ellis, H.J.C.; Morelli, R.A.; Hislop, G.W., "Work in progress - challenges to educating students within the Community of Open Source Software for Humanity," in Frontiers in Education Conference, 2008. FIE 2008. 38th Annual , vol., no., pp.S3H-7-S3H-8, 22-25 Oct. 2008. DOI=http://dx.doi.org/10.1109/FIE.2008.4720515<br />
<br />
* Ellis, H.; Morelli, R.A.; Hislop, G.W., "Support for Educating Software Engineers Through Humanitarian Open Source Projects," in Software Engineering Education and Training Workshop, 2008. CSEETW '08. 21st IEEE-CS Conference on , vol., no., pp.1-4, 14-17 April 2008. DOI=http://dx.doi.org/10.1109/CSEETW.2008.5<br />
<br />
* Ellis, H.J.C.; Hislop, G.W., "Fostering the Community of Software Engineering Educators," in Software Engineering Education and Training, 2008. CSEET '08. IEEE 21st Conference on , vol., no., pp.233-237, 14-17 April 2008. DOI=http://dx.doi.org/10.1109/CSEET.2008.18<br />
<br />
* Ellis, H.J.C.; Morelli, R.A.; de Lanerolle, T.R.; Hislop, G.W., "Holistic Software Engineering Education Based on a Humanitarian Open Source Project," in Software Engineering Education & Training, 2007. CSEET '07. 20th Conference on , vol., no., pp.327-335, 3-5 July 2007. DOI=http://dx.doi.org/10.1109/CSEET.2007.26<br />
<br />
* Morelli, R.A., Ellis, H.J.C., de Lanerolle, T., Damon, J., and Walti, C., “Can Student-Written Software Help Sustain Humanitarian FOSS?”, The 4th International Conference on Information Systems for Crisis Response and Management, Delft, the Netherlands, May 2007, pp. 41-44. PDF:http://www.cs.trincoll.edu/~ram/ram/MorelliEtAl_ISCRAM07.pdf<br />
<br />
* Heidi J. C. Ellis, Ralph A. Morelli, Trishan R. de Lanerolle, Jonathan Damon, and Jonathan Raye. 2007. Can humanitarian open-source software development draw new students to CS?. SIGCSE Bull. 39, 1 (March 2007), 551-555. DOI=http://dx.doi.org/10.1145/1227504.1227495<br />
<br />
<br />
Conferences<br />
* Hislop, Gregory W. and Ellis, Heidi J. C. (2016). Building the Student Pipeline to Open Source Communities using HFOSS. 2016 Red Hat Summit.<br />
<br />
* Ellis, Heidi J. C. and Hislop, Gregory W. (2016). Want Students Ready to Contribute? Let’s Discuss What They Should Know!. 2016 OSCON Everything Open Conference.<br />
<br />
== Panels and Posters ==<br />
<br />
* Weiss, Stewart and Klukowska, Joanna and Burge, Darci (2017). Injecting Open Source Content Into CS2/Data Structures Courses (poster). 22nd Annual Consortium For Computing Sciences in Colleges, Northeastern Conference. <br />
<br />
* Murphy, Christian and Buffardi, Kevin and Dehlinger, Josh and Lambert, Lynn, and Veilleux, Nanette (2017). Community Engagement with Free and Open Source Software (panel). 48th ACM SIGCSE Technical Symposium on Computer Science Education.<br />
<br />
* Ellis, Heidi J. C. and Hislop, Gregory W. and Burdge, Darci and Postner, Lori and Jackson, Stoney (2016). Learning via Student Participation in Humanitarian Free and Open Source Software Projects. NSF/AAAS conference on Envisioning the Future of Undergraduate STEM Education: Research and Practice.<br />
<br />
* Ellis, Heidi J. C. and Hislop, Gregory W. and Burdge, Darci and Postner, Lori and Jackson, Stoney and Kussmaul, Clif (2016). OpenPath – Improving Student Pathways to Computing Professions via Humanitarian Free and Open Source Software. NSF/AAAS conference on Envisioning the Future of Undergraduate STEM Education: Research and Practice.<br />
<br />
* Jackson, Stoney and Ellis, Heidi J. C. and Hislop, Gregory W. and Postner, Lori and Jackson, Stoney (2015). Team Project Experiences in Humanitarian Free and Open Source Software (HFOSS): Faculty Poster Abstract. J. Comput. Sci. Coll. USA.<br />
<br />
* Alkoby, Karen and Burdge, Darci and Morgan, Becka and Ordonez, Patti and Likins, Gina (2015). Humanitarian Free and Open Source Software: Motivating the Underrepresented. Grace Hopper Celebration of Women in Computing 2015.<br />
<br />
* Pulimood, S. M., Hislop, G.W., and Ellis, H.J.C., “A Multi-Institutional Study of Self-Perceived Learning via Student Involvement in HFOSS Projects,” Poster. CCSC-EA, Atlantic City NJ, Oct. 2015.<br />
<br />
* Gregory W. Hislop and Heidi J.C. Ellis. 2015. Practical Experiences for IT Students in Humanitarian Free and Open Source Software Projects. In Proceedings of the 16th Annual Conference on Information Technology Education (SIGITE '15). ACM, New York, NY, USA, 99-99. DOI=http://dx.doi.org/10.1145/2808006.2808042 <br />
<br />
* Gregory W. Hislop, Stoney Jackson, and Heidi J.C. Ellis. 2015. FOSS Artifacts for Evaluating Students on Team Projects. In Proceedings of the 16th Annual Conference on Information Technology Education (SIGITE '15). ACM, New York, NY, USA, 57-57. DOI=http://dx.doi.org/10.1145/2808006.2808009 <br />
<br />
* Jackson, S., Ellis H.J.C., Hislop, G.W., and Postner, L., “Team project experiences in humanitarian free and open source software (HFOSS)”: faculty poster abstract. J. Comput. Sci. Coll (CCSCNE '15). 30, 6 (June 2015), 156-157.<br />
<br />
* Ellis, H.J.C., Burdge, D., Morgan, R., Ordóñez, P. and Alkoby, K., “Using Humanitarian Free and Open Source Software (HFOSS) to Attract the Underrepresented to Computer Science,” 2015 ACM Richard Tapia Celebration of Diversity in Computing, Boston, MA. Panel.<br />
<br />
* Heidi J.C. Ellis and Gregory W. Hislop. 2014. Structuring software engineering learning within open source software participation. In Proceedings of the 2014 conference on Innovation & technology in computer science education (ITiCSE '14). ACM, New York, NY, USA, 326-326. DOI=http://dx.doi.org/10.1145/2591708.2602681 <br />
<br />
* Heidi J.C. Ellis, Gregory W. Hislop, and Joanmarie Diggs. 2013. Developing HFOSS projects using integrated teams across levels and institutions. In Proceedings of the 18th ACM conference on Innovation and technology in computer science education (ITiCSE '13). ACM, New York, NY, USA, 349-349. DOI=http://dx.doi.org/10.1145/2462476.2465613 <br />
<br />
* Heidi J.C. Ellis, Stoney Jackson, Darci Burdge, Lori Postner, Gregory W. Hislop, and Joanmarie Diggs. 2014. Learning within a professional environment: shared ownership of an HFOSS project. In Proceedings of the 2014 conference on Innovation & technology in computer science education (ITiCSE '14). ACM, New York, NY, USA, 337-337. DOI=http://dx.doi.org/10.1145/2591708.2602660 <br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Purcell, M.; Chua, M.; Dziallas, S., "Towards a model of faculty development for FOSS in education," in Software Engineering Education and Training (CSEE&T), 2013 IEEE 26th Conference on , vol., no., pp.269-273, 19-21 May 2013. DOI=http://dx.doi.org/10.1109/CSEET.2013.6595259<br />
<br />
* Purcell, M., Ellis, H.J.C., and Hislop, G.W. (2013). An Approach for Evaluating Open Source Projects for Student Participation. Poster at CCSC NE.<br />
<br />
* Ellis, H.J.C., and Hislop, G.W. (2013). Community-Based Student Learning via Participation in Humanitarian FOSS Projects. Poster at CCSC NE.<br />
<br />
*Ellis, H.J.C.,, Hislop, G.W., and Morelli, R.A., “SoftHum: Student Participation in the Community of Open Source Software for Humanity,” Poster, 2013 NSF/AASE Conference for Principle Investigators of the Transforming Undergraduate Education STEM program, January 23-25, 2013 Washington, D.C. <br />
<br />
* Ellis, H.J.C.,, Hislop, G.W., and Morelli, R.A., “HumIT: Student IT Services to Support Open Source Software for Humanity,” Poster, 2013 NSF/AASE Conference for Principle Investigators of the Transforming Undergraduate Education STEM program, January 23-25, 2013 Washington, D.C. <br />
<br />
* Clif Kussmaul, Heidi J.C. Ellis, and Gregory W. Hislop. 2012. 50 ways to be a FOSSer: simple ways to involve students & faculty (abstract only). In Proceedings of the 43rd ACM technical symposium on Computer Science Education (SIGCSE '12). ACM, New York, NY, USA, 671-671. DOI=http://dx.doi.org/10.1145/2157136.2157393 <br />
<br />
* Heidi J.C. Ellis and Gregory W. Hislop. 2011. Student IT services to support open source software for humanity. In Proceedings of the 2011 conference on Information technology education (SIGITE '11). ACM, New York, NY, USA, 307-308. DOI=http://dx.doi.org/10.1145/2047594.2047676 <br />
<br />
* Heidi J.C. Ellis, Gregory W. Hislop, and Ralph A. Morelli. 2011. A comparison of software engineering knowledge gained from student participation in humanitarian foss projects. In Proceedings of the 16th annual joint conference on Innovation and technology in computer science education (ITiCSE '11). ACM, New York, NY, USA, 360-360. DOI=http://dx.doi.org/10.1145/1999747.1999874 <br />
<br />
* Heidi J.C. Ellis and Gregory W. Hislop. 2011. Courseware: student learning via FOSS field trips. In Proceedings of the 16th annual joint conference on Innovation and technology in computer science education (ITiCSE '11). ACM, New York, NY, USA, 329-329. DOI=http://dx.doi.org/10.1145/1999747.1999840 <br />
<br />
* Heidi J.C. Ellis, Mel Chua, Matthew C. Jadud, and Gregory W. Hislop. 2011. Learning through open source participation. In Proceedings of the 42nd ACM technical symposium on Computer science education (SIGCSE '11). ACM, New York, NY, USA, 83-84. DOI=http://dx.doi.org/10.1145/1953163.1953191<br />
<br />
* Ellis, H.J.C., Hislop, G.W., and Morelli, R.A., “SoftHum: Student Participation in the Community of Open Source Software for Humanity,” Poster, NSF 2011 CCLI-TUES PIs Conference, Washington, DC, Jan. 26-28, 2011.<br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Chua, M.; Kussmaul, Clif; Burke, Matthew M., "Panel — Teaching students to participate in Open Source Software projects," in Frontiers in Education Conference (FIE), 2010 IEEE , vol., no., pp.F2B-1-F2B-2, 27-30 Oct. 2010. DOI=http://dx.doi.org/10.1109/FIE.2010.5673437<br />
<br />
* Bonhomme-Biais, A., Ellis, H.J.C., Lockwood, J., and Raschid, L., “Open Source for Good” Panel, Grace Hopper Celebration of Women in Computing, Washington, DC, Oct. 2010<br />
<br />
* Hislop, G.W., Ellis, H.J.C., DeKoenigsburg, G., and Jazayeri, D., “Student Participation in OSS Projects,” The 6th International Conference on Open Source Systems, Notre Dame, IN, June, 2010.<br />
<br />
* Heidi J. C. Ellis, Gregory W. Hislop, Ralph Morelli, and Norman Danner. 2010. Instructional aspects of student participation in humanitarian Free and Open Source Software: panel discussion. J. Comput. Sci. Coll. 25, 6 (June 2010), 152-154. <br />
<br />
* Ellis, H.J.C., Hislop, G.W., and Ibanez, L., “Opportunities for Students to Contribute to FOSS Projects,” O’Reilly Open Source Convention (OSCON), Portland, OR, July 19-23, 2010. [[http://cdn.oreillystatic.com/en/assets/1/event/45/Opportunities%20for%20Students%20to%20Contribute%20to%20FOSS%20Projects%20Presentation.odp .ODP]]<br />
<br />
== Related Efforts ==<br />
<br />
* Roca, Alberto and Robinson, Rosario and Murphy, Christian (2018). Learn About Open Source Software (Birds of a Feather). 2018 ACM Richard Tapia Celebration of Diversity in Computing.<br />
<br />
* Murphy, Christian and Weng, Judy and Pearce, Jan and Veilleux, Nanette (2017). Addressing Diversity &amp; Inclusion Issues in Computer Science through Contributions to Free and Open Source Software (Birds of a Feather). 2017 ACM Richard Tapia Celebration of Diversity in Computing.<br />
<br />
* Ellis, Heidi J.C. and Jackson, Stoney and Hislop, Gregory W. and Pulimood, S. Monisha and Likins, Gina (2016). Preparing to Teach Humanitarian Open Source (Abstract Only). Proceedings of the 47th ACM Technical Symposium on Computing Science Education. New York, NY, USA. Birds of a Feather Session (BoF) at SIGCSE Symposium.<br />
<br />
* Rebelsky, Sam A. and Morgan, Becka and Pulimood, S. Monisha and Postner, Lori and Hislop, Gregory W. (2015). Incorporating Humanitarian Free and Open Source Software in CS Classrooms. Grace Hopper Celebration of Women in Computing 2015. Birds of a Feather Session (BoF).<br />
<br />
* Postner, L., Jackson, S., Coleman, B., MelloStark, S., Rebelsky, S. (2015). Student Contributions to Humanitarian Free and Open Source Software (HFOSS). Birds of a Feather Session and abstract at SIGCSE 2015 Symposium.<br />
<br />
* Gregory W. Hislop, Heidi J.C. Ellis, Darci Burdge, Sean Goggins, Lori Postner, and Stoney Jackson. 2013. Encouraging faculty & student involvement in humanitarian free and open source software (HFOSS)(abstract only). In Proceeding of the 44th ACM technical symposium on Computer science education (SIGCSE '13). ACM, New York, NY, USA, 751-751. DOI=http://dx.doi.org/10.1145/2445196.2445481 <br />
<br />
* Wurst, K., Postner, L., and Jackson, S. (2014). Teaching Open Source (Software). Birds of a Feather Session (BoF) at SIGCSE Symposium.<br />
<br />
== Workshops ==<br />
* Burdge, Darci and Jackson, Stoney (2016). Git 101: Foundations for a Common Workflow to Contribute to HFOSS: Tutorial Presentation. J. Comput. Sci. Coll. 31 (6), 18-20. <br />
<br />
* Burdge, Darci and Jackson, Stoney (2016). Git 102: A Common Workflow to Contribute to HFOSS: Tutorial Presentation. J. Comput. Sci. Coll. 31 (6), 34-36.<br />
<br />
* Ellis, H.J.C., Jackson, S., Hislop, G.W., Postner, L., and Burdge, D. (2014). Getting Started in Open Source - A Tour of a Real Project. Workshop at CCSC NE.<br />
<br />
* Hislop, G.W., Burdge, D., Postner, L., and Ellis H.J.C (2013). Preparing for Student Participation in HFOSS Projects - FOSS Tools and Techniques. Workshop at CCSC E.<br />
<br />
* Ellis, H.J.C., and Hislop, G.W. (2013). Project Selection for Student Participation in Humanitarian FOSS. Workshop at the 26th Annual Conference on Software Engineering Education and Training (SIGITE).<br />
<br />
* Ellis, H.J.C., Hislop, G.W., and Purcell, M. (2013). Project Selection for Student Involvement in Humanitarian FOSS. Workshop at 26th Annual Conference on Software Engineering Education and Training (CSEET). San Francisco.<br />
<br />
* Ellis, H.J.C., Hislop, G.W., Purcell, M., and Postner, L. (2013). Project Selection for Student Participation in Humanitarian FOSS. Workshop at CCSC NE.<br />
<br />
* Ellis, H.J.C., and Hislop, G.W., “Project Selection for Student Participation in Humanitarian FOSS,” 26th Annual Conference on Software Engineering Education and Training, San Francisco, May. 2013<br />
<br />
* Ellis, H.J.C., and Hislop, G.W., “Student Participation in Humanitarian Open Source Software (HFOSS),” Lightening Talk, 2011 International Computing Education Research Workshop, Providence, RI, August, 2011. <br />
<br />
* Morelli, R.A., Danner, N., Iyengar, J., de Lanerolle, T. R., and Ellis, H.J.C., “Teaching and Building Humanitarian Open Source Software,” SIGCSE 2008, Technical Symposium on Computer Science Education, Portland OR, Mar. 2008.<br />
<br />
* Morelli, R.A., Danner, N., Iyengar, J., de Lanerolle, T. R., and Ellis, H.J.C., “Teaching and Building Humanitarian Open Source Software,” SIGCSE 2008, Technical Symposium on Computer Science Education, Portland OR, Mar. 2008.<br />
<br />
<br />
[[Category:Reference]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Stage_2_Activities/Stage_3_Planning_-_Diversity%26InclusionStage 2 Activities/Stage 3 Planning - Diversity&Inclusion2018-06-20T16:53:23Z<p>Cmurphy: /* Group Participants */</p>
<hr />
<div>== Group Participants ==<br />
*Alberto Roca <info@EquitableTech.org><br />
*[[user:cmurphy | Chris Murphy]] <cdmurphy@seas.upenn.edu><br />
<br />
== Planning an Initial (H)FOSS (Learning) Activity ==<br />
(Please discuss and record your group's approach for an initial (learning) activity. When you have a good draft description of the (learning) activity using the sections below, you could create a (learning) activity page for it by copying the [[Learning Activity Format with Directions]].)<br />
<br />
As a meta topic, this project not specifically for a "learning activity". To start, this project will summarize current (H)FOSS/POSSE diversity, equity, and inclusion work. In future, learning activities may develop. Instead will currently focus on DE&I resources to be used by instructors and students as they explore/learn HFOSS. [Roca 20-June-2018]<br />
<br />
<br />
=== Project targeted for the activity ===<br />
<br />
=== Brief description of the activity ===<br />
<br />
=== Time you expect the (H)FOSS activity to take ===<br />
e.g. # classes, # homework assignments, # lab activities, etc.<br />
<br />
(Whether the activity will be completed in class or out of class)<br />
<br />
=== (Relationship of this activity to course goals/objectives) ===<br />
<br />
=== What students/faculty/etc will submit upon completion of the activity ===<br />
<br />
=== Approach for assessing the work ===<br />
<br />
=== Questions or concerns you have about implementing your activity ===<br />
<br />
=== Support you will need to implement your activity ===<br />
<br />
== Planning Stage 3 Activities ==<br />
<br />
=== Meetings ===<br />
<Identify meeting times. Find out (H)FOSS project meeting times.><br />
*Grace Hopper OSS BoF [http://www.example.com xxLINK TBD]<br />
*Tapia [http://www.tapiaconference.org/schedule/friday-september-21-2018/330pm-430pm/learn-about-open-source-software/ OSS BoF]<br />
<br />
===Specific Tasks===<br />
<What will various group members do.> <br />
<br />
<br />
== Resources / Models ==<br />
<List any resources that you find><br />
<br />
xxTODO-HIGH<br />
<br />
=== DE&I Research/Advocacy/Intervention Efforts ===<br />
General<br />
*[http://EquitableTech.org EquitableTech.org] producing OSS workshops at Minority-Serving Institutions in USA<br />
*[http://www.minoritypostdoc.org/view/resources.html#entrepreneurship Tech opportunities] (not specifically FOSS)<br />
*[http://openhatch.org OpenHatch] campus OSS workshops (events defunct)<br />
<br />
Academia<br />
*(any?)<br />
<br />
Industry<br />
*[https://www.outreachy.org Outreachy]<br />
*[https://chaoss.community/metrics/ CHAOSS] Diversity & Inclusion working group of Community Health Analytics Open Source Software<br />
<br />
=== Opportunities (especially for students) ===<br />
*Hack for Impact; UPenn<br />
<br />
<br />
=== DE&I Articles ===<br />
*Roca xxTODO (include citations)<br />
*Jensen xxTODO<br />
*Murphy xxTODO<br />
*Dryden xxTODO<br />
<br />
== Other Notes ==<br />
<br />
Prior related POSSE groups, participants, content, etc, if any:<br />
<br />
xxTODO diversity analysis of following POSSE nodes (drawing from NSF reports?):<br />
<br />
=== POSSE Institutions ===<br />
*teaching v research type: research-intensive, PUI-4-year, Community College, etc<br />
*mission: HBCU, HSI, Tribal, parochial, private, public, etc<br />
<br />
=== Summary demographics of POSSE participants ===<br />
*gender<br />
*ethnicity<br />
*etc<br />
<br />
<br />
<br />
<br />
[[Category:POSSE]]<br />
<br />
(When creating an activity, remove it from the Formats category.)<br />
[[Category:Formats]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Stage_2_Activities/Stage_3_Planning_-_Diversity%26InclusionStage 2 Activities/Stage 3 Planning - Diversity&Inclusion2018-06-20T16:50:35Z<p>Cmurphy: /* Group Participants */</p>
<hr />
<div>== Group Participants ==<br />
*Alberto Roca <info@EquitableTech.org><br />
*Chris Murphy <cdmurphy@seas.upenn.edu><br />
<br />
== Planning an Initial (H)FOSS (Learning) Activity ==<br />
(Please discuss and record your group's approach for an initial (learning) activity. When you have a good draft description of the (learning) activity using the sections below, you could create a (learning) activity page for it by copying the [[Learning Activity Format with Directions]].)<br />
<br />
As a meta topic, this project not specifically for a "learning activity". To start, this project will summarize current (H)FOSS/POSSE diversity, equity, and inclusion work. In future, learning activities may develop. Instead will currently focus on DE&I resources to be used by instructors and students as they explore/learn HFOSS. [Roca 20-June-2018]<br />
<br />
<br />
=== Project targeted for the activity ===<br />
<br />
=== Brief description of the activity ===<br />
<br />
=== Time you expect the (H)FOSS activity to take ===<br />
e.g. # classes, # homework assignments, # lab activities, etc.<br />
<br />
(Whether the activity will be completed in class or out of class)<br />
<br />
=== (Relationship of this activity to course goals/objectives) ===<br />
<br />
=== What students/faculty/etc will submit upon completion of the activity ===<br />
<br />
=== Approach for assessing the work ===<br />
<br />
=== Questions or concerns you have about implementing your activity ===<br />
<br />
=== Support you will need to implement your activity ===<br />
<br />
== Planning Stage 3 Activities ==<br />
<br />
=== Meetings ===<br />
<Identify meeting times. Find out (H)FOSS project meeting times.><br />
*Grace Hopper OSS BoF [http://www.example.com xxLINK TBD]<br />
*Tapia [http://www.tapiaconference.org/schedule/friday-september-21-2018/330pm-430pm/learn-about-open-source-software/ OSS BoF]<br />
<br />
===Specific Tasks===<br />
<What will various group members do.> <br />
<br />
<br />
== Resources / Models ==<br />
<List any resources that you find><br />
<br />
xxTODO-HIGH<br />
<br />
=== DE&I Research/Advocacy/Intervention Efforts ===<br />
General<br />
*[http://EquitableTech.org EquitableTech.org] producing OSS workshops at Minority-Serving Institutions in USA<br />
*[http://www.minoritypostdoc.org/view/resources.html#entrepreneurship Tech opportunities] (not specifically FOSS)<br />
*[http://openhatch.org OpenHatch] campus OSS workshops (events defunct)<br />
<br />
Academia<br />
*(any?)<br />
<br />
Industry<br />
*[https://www.outreachy.org Outreachy]<br />
*[https://chaoss.community/metrics/ CHAOSS] Diversity & Inclusion working group of Community Health Analytics Open Source Software<br />
<br />
=== Opportunities (especially for students) ===<br />
*Hack for Impact; UPenn<br />
<br />
<br />
=== DE&I Articles ===<br />
*Roca xxTODO (include citations)<br />
*Jensen xxTODO<br />
*Murphy xxTODO<br />
*Dryden xxTODO<br />
<br />
== Other Notes ==<br />
<br />
Prior related POSSE groups, participants, content, etc, if any:<br />
<br />
xxTODO diversity analysis of following POSSE nodes (drawing from NSF reports?):<br />
<br />
=== POSSE Institutions ===<br />
*teaching v research type: research-intensive, PUI-4-year, Community College, etc<br />
*mission: HBCU, HSI, Tribal, parochial, private, public, etc<br />
<br />
=== Summary demographics of POSSE participants ===<br />
*gender<br />
*ethnicity<br />
*etc<br />
<br />
<br />
<br />
<br />
[[Category:POSSE]]<br />
<br />
(When creating an activity, remove it from the Formats category.)<br />
[[Category:Formats]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Stage_2_ActivitiesStage 2 Activities2018-06-20T14:25:21Z<p>Cmurphy: /* Schedule for POSSE 2018-06 in Philadelphia */</p>
<hr />
<div>__NOTOC__<br />
= Objectives =<br />
<br />
Participants completing the Stage 2 workshop will be able to:<br />
<br />
* Describe the variety of learning activities that student participation in HFOSS projects may include<br />
* Implement HFOSS activities appropriate for a particular curriculum and student population<br />
* Explain challenges and opportunities of student HFOSS participation<br />
* Discuss key aspects of FOSS culture and process <br />
* Use a selection of tools common in HFOSS projects<br />
* Select an HFOSS project well-suited for student participation<br />
* Identify key sources of information for learning about HFOSS<br />
* Identify other participants with similar ideas about applying HFOSS<br />
* Participate in POSSE Stage 3<br />
<br />
== Quick Links == <br />
*[https://drive.google.com/drive/folders/1Wl7HTDmcRNRWQmVVNAeeRHmw2kz-6SM8 Google Drive for Activities]<br />
*[https://pad.riseup.net/p/Intro_A-H Introductions - Last Name A-H]<br />
*[https://pad.riseup.net/p/Intro_I-Z Introductions - Last Name I-Z]<br />
*[https://docs.google.com/document/d/1AX94AXwj-MIOuDGMdQ1ugRmofDlKNJ1FXF8c44OuINI/edit Introductions - if you can't access the Rise-up Pad]<br />
<br />
= Schedule for POSSE 2018-06 in Philadelphia =<br />
<br />
Below is the schedule for the stage 2 workshop activities. <br />
{|border="1"<br />
! Time<br />
! Activity<br />
! Team<br />
|- <br />
|<br />
! Day 1 (Afternoon and Evening)<br />
|<br />
|-<br />
| 1:30 PM<br />
| Leave the hotel for POSSE<br />
| All<br />
|-<br />
| 2:00 <br />
| 1.1 Welcome<br />
* Plan for the day<br />
* Welcome to Philadelphia<br />
* Introducing everyone<br />
* Workshop overview and schedule<br />
| Greg, Lori<br />
|-<br />
| 2:45<br />
| 1.2 HFOSS in Education - (Activity 75 minutes, Slides 15 minutes)<br />
* 50 Ways to be a FOSSer<br />
* Exploration of student contributions <br />
| Chris, Heidi<br />
|-<br />
| 4:15<br />
| Break<br />
| All<br />
|-<br />
| 4:30<br />
| 1.3 HFOSS Process and Tools<br />
* How tools fit and support HFOSS culture<br />
* Upstream Adoption<br />
* Licensing<br />
| Darci, Gina<br />
|-<br />
| 5:00<br />
| GitHub Education<br />
| [http://mozzadrella.me/ Vanessa]<br />
|-<br />
| 5:15<br />
| Dinner - working / social dinner<br />
| All<br />
|-<br />
| 6:15<br />
| 1.4 Git Intro Activity<br />
* [https://github.com/StoneyJackson/git-intro-activity Hands-on exploration] of managing a local repository <br />
| Becka, Stoney<br />
|-<br />
| 8:00<br />
| Return to the hotel<br />
| All<br />
|-<br />
| 8:30<br />
| Social Hour - Optional<br />
| All<br />
|- <br />
|<br />
! Day 2<br />
|<br />
|- <br />
| 7:45<br />
| Leave the hotel for POSSE<br />
| All<br />
|-<br />
| 8:00<br />
| Breakfast<br />
| All<br />
|-<br />
| 8:30<br />
| 2.1 Approach to HFOSS Learning<br />
* POGIL<br />
* Pathways<br />
| Greg, Clif<br />
|-<br />
| 9:15<br />
| 2.2 GitHub Workflow Activity<br />
* [https://github.com/StoneyJackson/github-workflow-activity A common workflow] for HFOSS contribution<br />
| Darci, Stoney<br />
|-<br />
| <br />
| Take Break When Convenient<br />
| All<br />
|-<br />
| 11:00<br />
| 2.3 Understanding Open Source Communities<br />
* Perspective on basic characteristics common in HFOSS communities<br />
** FOSSisms that capture FOSS culture and methods<br />
| Chris, Clif<br />
|-<br />
| 12:15<br />
| Mozilla Open Source Student Network<br />
* [https://opensource.mozilla.community/] <br />
| Christos<br />
|-<br />
| 12:30<br />
| Lunch <br />
| All<br />
|-<br />
| 1:30<br />
| 2.4 HFOSS in the Curriculum Activity (60 minutes)<br />
* Discussion (15 minutes)<br />
** Options for getting started in courses<br />
** HFOSS beyond the curriculum <br />
** Trying to find the right size student project<br />
** Evaluating student work<br />
** Instructional style: mentoring vs. lecturing; instructor as co-learner<br />
| Becka, Clif<br />
|-<br />
| 2:30<br />
| 2.5 Project Evaluation Activity<br />
| Darci, Lori<br />
|-<br />
| 3:15<br />
| Linux Foundation - Open Source Networking<br />
| Trishan<br />
|-<br />
| 3:30<br />
| Break<br />
| All<br />
|-<br />
| 3:45<br />
| 2.6 Planning for HFOSS Participation<br />
* Form groups (based either on courses or HFOSS projects)<br />
* In each group:<br />
** Download and install dev environment for HFOSS project if appropriate<br />
** Identify three things that you would like to get done by the end of POSSE<br />
** Plan a schedule for accomplishing these<br />
| Heidi<br />
|-<br />
| 6:00 <br />
| Dinner - Pietro's, 1714 Walnut St.<br />
| All<br />
|- <br />
|<br />
! Day 3<br />
|<br />
|-<br />
| 7:45<br />
| Leave the hotel (checkout first)<br />
| All<br />
|-<br />
| 8:00<br />
| Breakfast <br />
| All<br />
|-<br />
| 8:30<br />
| 3.1 Understanding POSSE Stage 3<br />
* Experience reports<br />
** [http://www.seas.upenn.edu/~cdmurphy/foss/Murphy-POSSE-June2018.pptx Chris' slides]<br />
| Greg, [[user:cmurphy | Chris]], Becka, Darci<br />
|-<br />
| 9:30 <br />
| <br />
3.2 Sharing HFOSS Learning Activities<br />
* Review of Activity Template<br />
* Group work<br />
| Heidi<br />
|-<br />
| 10:30<br />
| Break<br />
| All<br />
|-<br />
| 10:45<br />
| 3.2 Sharing HFOSS Learning Activities - Continued<br />
* [http://foss2serve.org/index.php/Stage_2_Activities/Stage_3_Planning_-_Format Stage 3 Planning Template]<br />
| All<br />
|-<br />
| 11:45<br />
| Red Hat University Outreach <br />
| Gina<br />
|-<br />
| 12:00<br />
| Lunch - Lunch Entertainment: [https://drexel.qualtrics.com/jfe/form/SV_72jbRS6I6TsrIyx Evaluation Form] <br />
| All<br />
|-<br />
| 12:45<br />
| 3.2 Sharing HFOSS Learning Activities - Continued<br />
* Groups report back on work done before lunch<br />
* Groups continue to work <br />
| All<br />
|-<br />
| 1:45 <br />
| 3.3 Stage 3 - First Steps<br />
* What will the group do together?<br />
* Plan some initial activities (faculty only or faculty and students)<br />
* Discuss group communication<br />
* Assessment<br />
| Heidi, Clif<br />
|-<br />
| 2:45<br />
| 3.4 Going Forward<br />
* Evaluation form<br />
* Open discussion <br />
* Closing remarks<br />
| Greg<br />
|-<br />
| 3:30<br />
| End - shuttles and taxi to airport<br />
| All<br />
|}<br />
<br />
= Downloads =<br />
<!-- * [https://drive.google.com/open?id=0B92hZzmXFmvQQlZnZG1EdGhSZEk Presentation Materials - Stage 2 - Day 1] --><br />
<!-- <br />
* [https://drive.google.com/drive/folders/0B1g5HGhZ4fOuU3ZIU0pRZkpKOG8 Presentation materials for stage 2]<br />
* [https://github.com/StoneyJackson/CollabDev Stoney's Git and GitHub Activities]<br />
* [https://docs.google.com/presentation/d/1YYi3STtYoMAfSc59bjz46Sqx4tkYgPhCvDKs5W9Lxew/edit?usp=sharing Matt's presentation] on Mozilla's Campus Clubs<br />
--><br />
<br />
<!-- = Shared Files Folder =<br />
<br />
* [https://drive.google.com/drive/folders/0B2rMbpfK2ojueVE3VmlvUUdCOUE?usp=sharing Google Drive folder for team activities] --><br />
<br />
= IRC =<br />
* Server: '''irc.freenode.net'''<br />
* Channel: '''#foss2serve'''<br />
<br />
Standard IRC clients may not work at some workshop locations due to port blockage. If you have problems, please let the team know and try one of the Web-based IRC interfaces below.<br />
<br />
=== Web-based IRC Clients ===<br />
<br />
* http://webchat.freenode.net/ (has a limit from one IP)<br />
* https://kiwiirc.com/client/irc.freenode.net/ <br />
* http://www.mibbit.com/<br />
<br />
== Logs ==<br />
<!-- <br />
* Thursday: <br />
** Minutes: <br />
** Log: <br />
<br />
* Friday: <br />
** Minutes: <br />
** Log: <br />
<br />
* Saturday:<br />
** Minutes:<br />
** Log:<br />
--><br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:POSSE]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Stage_2_ActivitiesStage 2 Activities2018-06-20T12:25:42Z<p>Cmurphy: /* Schedule for POSSE 2018-06 in Philadelphia */</p>
<hr />
<div>__NOTOC__<br />
= Objectives =<br />
<br />
Participants completing the Stage 2 workshop will be able to:<br />
<br />
* Describe the variety of learning activities that student participation in HFOSS projects may include<br />
* Implement HFOSS activities appropriate for a particular curriculum and student population<br />
* Explain challenges and opportunities of student HFOSS participation<br />
* Discuss key aspects of FOSS culture and process <br />
* Use a selection of tools common in HFOSS projects<br />
* Select an HFOSS project well-suited for student participation<br />
* Identify key sources of information for learning about HFOSS<br />
* Identify other participants with similar ideas about applying HFOSS<br />
* Participate in POSSE Stage 3<br />
<br />
== Quick Links == <br />
*[https://drive.google.com/drive/folders/1Wl7HTDmcRNRWQmVVNAeeRHmw2kz-6SM8 Google Drive for Activities]<br />
*[https://pad.riseup.net/p/Intro_A-H Introductions - Last Name A-H]<br />
*[https://pad.riseup.net/p/Intro_I-Z Introductions - Last Name I-Z]<br />
*[https://docs.google.com/document/d/1AX94AXwj-MIOuDGMdQ1ugRmofDlKNJ1FXF8c44OuINI/edit Introductions - if you can't access the Rise-up Pad]<br />
<br />
= Schedule for POSSE 2018-06 in Philadelphia =<br />
<br />
Below is the schedule for the stage 2 workshop activities. <br />
{|border="1"<br />
! Time<br />
! Activity<br />
! Team<br />
|- <br />
|<br />
! Day 1 (Afternoon and Evening)<br />
|<br />
|-<br />
| 1:30 PM<br />
| Leave the hotel for POSSE<br />
| All<br />
|-<br />
| 2:00 <br />
| 1.1 Welcome<br />
* Plan for the day<br />
* Welcome to Philadelphia<br />
* Introducing everyone<br />
* Workshop overview and schedule<br />
| Greg, Lori<br />
|-<br />
| 2:45<br />
| 1.2 HFOSS in Education - (Activity 75 minutes, Slides 15 minutes)<br />
* 50 Ways to be a FOSSer<br />
* Exploration of student contributions <br />
| Chris, Heidi<br />
|-<br />
| 4:15<br />
| Break<br />
| All<br />
|-<br />
| 4:30<br />
| 1.3 HFOSS Process and Tools<br />
* How tools fit and support HFOSS culture<br />
* Upstream Adoption<br />
* Licensing<br />
| Darci, Gina<br />
|-<br />
| 5:00<br />
| GitHub Education<br />
| [http://mozzadrella.me/ Vanessa]<br />
|-<br />
| 5:15<br />
| Dinner - working / social dinner<br />
| All<br />
|-<br />
| 6:15<br />
| 1.4 Git Intro Activity<br />
* [https://github.com/StoneyJackson/git-intro-activity Hands-on exploration] of managing a local repository <br />
| Becka, Stoney<br />
|-<br />
| 8:00<br />
| Return to the hotel<br />
| All<br />
|-<br />
| 8:30<br />
| Social Hour - Optional<br />
| All<br />
|- <br />
|<br />
! Day 2<br />
|<br />
|- <br />
| 7:45<br />
| Leave the hotel for POSSE<br />
| All<br />
|-<br />
| 8:00<br />
| Breakfast<br />
| All<br />
|-<br />
| 8:30<br />
| 2.1 Approach to HFOSS Learning<br />
* POGIL<br />
* Pathways<br />
| Greg, Clif<br />
|-<br />
| 9:15<br />
| 2.2 GitHub Workflow Activity<br />
* [https://github.com/StoneyJackson/github-workflow-activity A common workflow] for HFOSS contribution<br />
| Darci, Stoney<br />
|-<br />
| <br />
| Take Break When Convenient<br />
| All<br />
|-<br />
| 11:00<br />
| 2.3 Understanding Open Source Communities<br />
* Perspective on basic characteristics common in HFOSS communities<br />
** FOSSisms that capture FOSS culture and methods<br />
| Chris, Clif<br />
|-<br />
| 12:15<br />
| Mozilla Open Source Student Network<br />
* [https://opensource.mozilla.community/] <br />
| Christos<br />
|-<br />
| 12:30<br />
| Lunch <br />
| All<br />
|-<br />
| 1:30<br />
| 2.4 HFOSS in the Curriculum Activity (60 minutes)<br />
* Discussion (15 minutes)<br />
** Options for getting started in courses<br />
** HFOSS beyond the curriculum <br />
** Trying to find the right size student project<br />
** Evaluating student work<br />
** Instructional style: mentoring vs. lecturing; instructor as co-learner<br />
| Becka, Clif<br />
|-<br />
| 2:30<br />
| 2.5 Project Evaluation Activity<br />
| Darci, Lori<br />
|-<br />
| 3:15<br />
| Linux Foundation - Open Source Networking<br />
| Trishan<br />
|-<br />
| 3:30<br />
| Break<br />
| All<br />
|-<br />
| 3:45<br />
| 2.6 Planning for HFOSS Participation<br />
* Form groups (based either on courses or HFOSS projects)<br />
* In each group:<br />
** Download and install dev environment for HFOSS project if appropriate<br />
** Identify three things that you would like to get done by the end of POSSE<br />
** Plan a schedule for accomplishing these<br />
| Heidi<br />
|-<br />
| 6:00 <br />
| Dinner - Pietro's, 1714 Walnut St.<br />
| All<br />
|- <br />
|<br />
! Day 3<br />
|<br />
|-<br />
| 7:45<br />
| Leave the hotel (checkout first)<br />
| All<br />
|-<br />
| 8:00<br />
| Breakfast <br />
| All<br />
|-<br />
| 8:30<br />
| 3.1 Understanding POSSE Stage 3<br />
* Experience reports<br />
** [http://www.seas.upenn.edu/~cdmurphy/foss/Murphy-POSSE-June2018.pptx Chris' slides]<br />
| Greg, [[user:cmurphy | Chris]], Becka, Darci<br />
|-<br />
| 9:30 <br />
| <br />
3.2 Sharing HFOSS Learning Activities<br />
* Review of Activity Template<br />
* Group work<br />
| Heidi<br />
|-<br />
| 10:30<br />
| Break<br />
| All<br />
|-<br />
| 10:45<br />
| 3.2 Sharing HFOSS Learning Activities - Continued<br />
| All<br />
|-<br />
| 11:45<br />
| Red Hat University Outreach <br />
| Gina<br />
|-<br />
| 12:00<br />
| Lunch - Lunch Entertainment: [https://drexel.qualtrics.com/jfe/form/SV_72jbRS6I6TsrIyx Evaluation Form] <br />
| All<br />
|-<br />
| 12:45<br />
| 3.2 Sharing HFOSS Learning Activities - Continued<br />
* Groups report back on work done before lunch<br />
* Groups continue to work <br />
| All<br />
|-<br />
| 1:45 <br />
| 3.3 Stage 3 - First Steps<br />
* What will the group do together?<br />
* Plan some initial activities (faculty only or faculty and students)<br />
* Discuss group communication<br />
* Assessment<br />
| Heidi, Clif<br />
|-<br />
| 2:45<br />
| 3.4 Going Forward<br />
* Evaluation form<br />
* Open discussion <br />
* Closing remarks<br />
| Greg<br />
|-<br />
| 3:30<br />
| End - shuttles and taxi to airport<br />
| All<br />
|}<br />
<br />
= Downloads =<br />
<!-- * [https://drive.google.com/open?id=0B92hZzmXFmvQQlZnZG1EdGhSZEk Presentation Materials - Stage 2 - Day 1] --><br />
<!-- <br />
* [https://drive.google.com/drive/folders/0B1g5HGhZ4fOuU3ZIU0pRZkpKOG8 Presentation materials for stage 2]<br />
* [https://github.com/StoneyJackson/CollabDev Stoney's Git and GitHub Activities]<br />
* [https://docs.google.com/presentation/d/1YYi3STtYoMAfSc59bjz46Sqx4tkYgPhCvDKs5W9Lxew/edit?usp=sharing Matt's presentation] on Mozilla's Campus Clubs<br />
--><br />
<br />
<!-- = Shared Files Folder =<br />
<br />
* [https://drive.google.com/drive/folders/0B2rMbpfK2ojueVE3VmlvUUdCOUE?usp=sharing Google Drive folder for team activities] --><br />
<br />
= IRC =<br />
* Server: '''irc.freenode.net'''<br />
* Channel: '''#foss2serve'''<br />
<br />
Standard IRC clients may not work at some workshop locations due to port blockage. If you have problems, please let the team know and try one of the Web-based IRC interfaces below.<br />
<br />
=== Web-based IRC Clients ===<br />
<br />
* http://webchat.freenode.net/ (has a limit from one IP)<br />
* https://kiwiirc.com/client/irc.freenode.net/ <br />
* http://www.mibbit.com/<br />
<br />
== Logs ==<br />
<!-- <br />
* Thursday: <br />
** Minutes: <br />
** Log: <br />
<br />
* Friday: <br />
** Minutes: <br />
** Log: <br />
<br />
* Saturday:<br />
** Minutes:<br />
** Log:<br />
--><br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:POSSE]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Stage_2_ActivitiesStage 2 Activities2018-06-20T10:38:38Z<p>Cmurphy: /* Schedule for POSSE 2018-06 in Philadelphia */</p>
<hr />
<div>__NOTOC__<br />
= Objectives =<br />
<br />
Participants completing the Stage 2 workshop will be able to:<br />
<br />
* Describe the variety of learning activities that student participation in HFOSS projects may include<br />
* Implement HFOSS activities appropriate for a particular curriculum and student population<br />
* Explain challenges and opportunities of student HFOSS participation<br />
* Discuss key aspects of FOSS culture and process <br />
* Use a selection of tools common in HFOSS projects<br />
* Select an HFOSS project well-suited for student participation<br />
* Identify key sources of information for learning about HFOSS<br />
* Identify other participants with similar ideas about applying HFOSS<br />
* Participate in POSSE Stage 3<br />
<br />
== Quick Links == <br />
*[https://drive.google.com/drive/folders/1Wl7HTDmcRNRWQmVVNAeeRHmw2kz-6SM8 Google Drive for Activities]<br />
*[https://pad.riseup.net/p/Intro_A-H Introductions - Last Name A-H]<br />
*[https://pad.riseup.net/p/Intro_I-Z Introductions - Last Name I-Z]<br />
*[https://docs.google.com/document/d/1AX94AXwj-MIOuDGMdQ1ugRmofDlKNJ1FXF8c44OuINI/edit Introductions - if you can't access the Rise-up Pad]<br />
<br />
= Schedule for POSSE 2018-06 in Philadelphia =<br />
<br />
Below is the schedule for the stage 2 workshop activities. <br />
{|border="1"<br />
! Time<br />
! Activity<br />
! Team<br />
|- <br />
|<br />
! Day 1 (Afternoon and Evening)<br />
|<br />
|-<br />
| 1:30 PM<br />
| Leave the hotel for POSSE<br />
| All<br />
|-<br />
| 2:00 <br />
| 1.1 Welcome<br />
* Plan for the day<br />
* Welcome to Philadelphia<br />
* Introducing everyone<br />
* Workshop overview and schedule<br />
| Greg, Lori<br />
|-<br />
| 2:45<br />
| 1.2 HFOSS in Education - (Activity 75 minutes, Slides 15 minutes)<br />
* 50 Ways to be a FOSSer<br />
* Exploration of student contributions <br />
| Chris, Heidi<br />
|-<br />
| 4:15<br />
| Break<br />
| All<br />
|-<br />
| 4:30<br />
| 1.3 HFOSS Process and Tools<br />
* How tools fit and support HFOSS culture<br />
* Upstream Adoption<br />
* Licensing<br />
| Darci, Gina<br />
|-<br />
| 5:00<br />
| GitHub Education<br />
| [http://mozzadrella.me/ Vanessa]<br />
|-<br />
| 5:15<br />
| Dinner - working / social dinner<br />
| All<br />
|-<br />
| 6:15<br />
| 1.4 Git Intro Activity<br />
* [https://github.com/StoneyJackson/git-intro-activity Hands-on exploration] of managing a local repository <br />
| Becka, Stoney<br />
|-<br />
| 8:00<br />
| Return to the hotel<br />
| All<br />
|-<br />
| 8:30<br />
| Social Hour - Optional<br />
| All<br />
|- <br />
|<br />
! Day 2<br />
|<br />
|- <br />
| 7:45<br />
| Leave the hotel for POSSE<br />
| All<br />
|-<br />
| 8:00<br />
| Breakfast<br />
| All<br />
|-<br />
| 8:30<br />
| 2.1 Approach to HFOSS Learning<br />
* POGIL<br />
* Pathways<br />
| Greg, Clif<br />
|-<br />
| 9:15<br />
| 2.2 GitHub Workflow Activity<br />
* [https://github.com/StoneyJackson/github-workflow-activity A common workflow] for HFOSS contribution<br />
| Darci, Stoney<br />
|-<br />
| <br />
| Take Break When Convenient<br />
| All<br />
|-<br />
| 11:00<br />
| 2.3 Understanding Open Source Communities<br />
* Perspective on basic characteristics common in HFOSS communities<br />
** FOSSisms that capture FOSS culture and methods<br />
| Chris, Clif<br />
|-<br />
| 12:15<br />
| Mozilla Open Source Student Network<br />
* [https://opensource.mozilla.community/] <br />
| Christos<br />
|-<br />
| 12:30<br />
| Lunch <br />
| All<br />
|-<br />
| 1:30<br />
| 2.4 HFOSS in the Curriculum Activity (60 minutes)<br />
* Discussion (15 minutes)<br />
** Options for getting started in courses<br />
** HFOSS beyond the curriculum <br />
** Trying to find the right size student project<br />
** Evaluating student work<br />
** Instructional style: mentoring vs. lecturing; instructor as co-learner<br />
| Becka, Clif<br />
|-<br />
| 2:30<br />
| 2.5 Project Evaluation Activity<br />
| Darci, Lori<br />
|-<br />
| 3:15<br />
| Linux Foundation - Open Source Networking<br />
| Trishan<br />
|-<br />
| 3:30<br />
| Break<br />
| All<br />
|-<br />
| 3:45<br />
| 2.6 Planning for HFOSS Participation<br />
* Form groups (based either on courses or HFOSS projects)<br />
* In each group:<br />
** Download and install dev environment for HFOSS project if appropriate<br />
** Identify three things that you would like to get done by the end of POSSE<br />
** Plan a schedule for accomplishing these<br />
| Heidi<br />
|-<br />
| 6:00 <br />
| Dinner - Pietro's, 1714 Walnut St.<br />
| All<br />
|- <br />
|<br />
! Day 3<br />
|<br />
|-<br />
| 7:45<br />
| Leave the hotel (checkout first)<br />
| All<br />
|-<br />
| 8:00<br />
| Breakfast <br />
| All<br />
|-<br />
| 8:30<br />
| 3.1 Understanding POSSE Stage 3<br />
* Experience reports<br />
| Greg, [[user:cmurphy | Chris]], Becka, Darci<br />
|-<br />
| 9:30 <br />
| <br />
3.2 Sharing HFOSS Learning Activities<br />
* Review of Activity Template<br />
* Group work<br />
| Heidi<br />
|-<br />
| 10:30<br />
| Break<br />
| All<br />
|-<br />
| 10:45<br />
| 3.2 Sharing HFOSS Learning Activities - Continued<br />
| All<br />
|-<br />
| 11:45<br />
| Red Hat University Outreach <br />
| Gina<br />
|-<br />
| 12:00<br />
| Lunch - Lunch Entertainment: [https://drexel.qualtrics.com/jfe/form/SV_72jbRS6I6TsrIyx Evaluation Form] <br />
| All<br />
|-<br />
| 12:45<br />
| 3.2 Sharing HFOSS Learning Activities - Continued<br />
* Groups report back on work done before lunch<br />
* Groups continue to work <br />
| All<br />
|-<br />
| 1:45 <br />
| 3.3 Stage 3 - First Steps<br />
* What will the group do together?<br />
* Plan some initial activities (faculty only or faculty and students)<br />
* Discuss group communication<br />
* Assessment<br />
| Heidi, Clif<br />
|-<br />
| 2:45<br />
| 3.4 Going Forward<br />
* Evaluation form<br />
* Open discussion <br />
* Closing remarks<br />
| Greg<br />
|-<br />
| 3:30<br />
| End - shuttles and taxi to airport<br />
| All<br />
|}<br />
<br />
= Downloads =<br />
<!-- * [https://drive.google.com/open?id=0B92hZzmXFmvQQlZnZG1EdGhSZEk Presentation Materials - Stage 2 - Day 1] --><br />
<!-- <br />
* [https://drive.google.com/drive/folders/0B1g5HGhZ4fOuU3ZIU0pRZkpKOG8 Presentation materials for stage 2]<br />
* [https://github.com/StoneyJackson/CollabDev Stoney's Git and GitHub Activities]<br />
* [https://docs.google.com/presentation/d/1YYi3STtYoMAfSc59bjz46Sqx4tkYgPhCvDKs5W9Lxew/edit?usp=sharing Matt's presentation] on Mozilla's Campus Clubs<br />
--><br />
<br />
<!-- = Shared Files Folder =<br />
<br />
* [https://drive.google.com/drive/folders/0B2rMbpfK2ojueVE3VmlvUUdCOUE?usp=sharing Google Drive folder for team activities] --><br />
<br />
= IRC =<br />
* Server: '''irc.freenode.net'''<br />
* Channel: '''#foss2serve'''<br />
<br />
Standard IRC clients may not work at some workshop locations due to port blockage. If you have problems, please let the team know and try one of the Web-based IRC interfaces below.<br />
<br />
=== Web-based IRC Clients ===<br />
<br />
* http://webchat.freenode.net/ (has a limit from one IP)<br />
* https://kiwiirc.com/client/irc.freenode.net/ <br />
* http://www.mibbit.com/<br />
<br />
== Logs ==<br />
<!-- <br />
* Thursday: <br />
** Minutes: <br />
** Log: <br />
<br />
* Friday: <br />
** Minutes: <br />
** Log: <br />
<br />
* Saturday:<br />
** Minutes:<br />
** Log:<br />
--><br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:POSSE]]</div>Cmurphyhttp://www.foss2serve.org/index.php/User:CmurphyUser:Cmurphy2018-06-19T14:39:23Z<p>Cmurphy: /* Chris Murphy */</p>
<hr />
<div>==Chris Murphy==<br />
<br />
I am an Associate Professor of Practice in the Dept. of Computer & Information Science at the University of Pennsylvania: http://www.seas.upenn.edu/~cdmurphy<br />
<br />
I first attended POSSE in November 2014 and have since attended three more, as well as two POSSE Roundup pre-symposium events at SIGCSE.<br />
<br />
My current interests include online education, student contributions to open source software projects, and how these affect diversity and inclusion within CS.<br />
<br />
Prior to joining Penn in 2010, I completed a PhD in Computer Science at Columbia University, where my research focused on software testing. Before that, I worked as a professional software developer in Boston, San Francisco, and London after earning a BS in Computer Engineering from Boston University.<br />
<br />
Somewhere along the way, I also spent two years teaching English in Seoul, but that's not really part of the narrative hahaha...<br />
<br />
I have occasionally taught a standalone course on open-source software development at Penn, though unfortunately I have not been able to teach it since Fall 2016. <br />
* A webpage with an overview of the course is available at http://www.seas.upenn.edu/~cdmurphy/foss/ and the full syllabus is on foss2serve [[FOSS Course, UPenn, Murphy|here]]. <br />
* Students were asked to maintain blogs describing their progress. Links to those blogs are available at https://chrismurphyonline.tumblr.com <br />
* Other resources not hosted on foss2serve are available at https://github.com/ChrisMurphyOnline/open-source-software-development-course<br />
<br />
I have a few publications and presentations regarding open source software, including:<br />
* [http://www.seas.upenn.edu/~cdmurphy/pubs/Weng-RESPECT2018.pdf "Bridging the Diversity Gap in Computer Science with a Course on Open Source Software"], J. Weng and C. Murphy, In Proc of the 3rd Annual IEEE STCBP Conference on Research on Equity & Sustained Participation in Engineering, Computing, and Technology (RESPECT), Baltimore MD, Feb 2018.<br />
* "Addressing Diversity & Inclusion Issues in Computer Science through Contributions to Free and Open Source Software" (Birds of a Feather session with J. Weng, N. Veilleux, and J. Pearce), 2017 ACM Richard Tapia Celebration of Diversity in Computing, Atlanta GA, Sept 21, 2017. <br />
* "Community Engagement with Free and Open Source Software" (panel moderator), 48th ACM SIGCSE Technical Symposium on Computer Science Education, Seattle WA, Mar 9, 2017. <br />
<br />
You can find out more in [http://www.seas.upenn.edu/~cdmurphy/ChrisMurphy-CV.pdf my CV] and on [https://www.linkedin.com/in/chrismurphyonline my LinkedIn page]!<br />
<br />
==POSSE 11-2014 Stage 1 Activities==<br />
Part A: Intro to IRC, Part 1===<br />
* How do people interact? briefly, but politely, and usually offering to help out or at least make helpful suggestions<br />
* What is the pattern of communication? generally focused on a particular issue: someone raises it and the others try to help out<br />
* Are there any terms that seem to have special meaning? technical terms, of course, but also the commands to MeetBot<br />
* Can you make any other observations? amber does not seem to be a big fan of capitalization and punctuation :-p<br />
<br />
Part A: Intro to IRC, Part 3===<br />
* I observed the #openMRS channel on Tues Oct 14.<br />
* There was a "global notice" that went to all freenode users; I didn't realize it at first, as I thought it was just for the channel users, but I see the difference now.<br />
* There was a conversation between two users in which one was attempting to help the other get the code downloaded and installed. <br />
* The OpenMRSBot occassionally sent messages based on activities in Jira<br />
* At 10am EDT, a user started the daily SCRUM meeting. Users were asked to give updates in order, however two of the three were absent<br />
* I noticed that most of the conversations were between two people, in which they included the other person's nickname at the start of their entry<br />
<br />
Part A: Project Anatomy===<br />
Sugar Labs====<br />
Community=====<br />
* Activity Team: develops and maintains many of the activities; there are 2 coordinators and 13 contributors<br />
* Development Team: build and maintain the core Sugar environment; there is no coordinator and 4 "people" listed; there is no overlap with the Activity team<br />
* Documentation Team: provide the Sugar community with high quality documentation; no coordinator or contributors are listed<br />
Tracker=====<br />
* types: defects and enhancements<br />
* info available for each ticket: ID#, reported by, owned by, priority, milestone, component, version, severity, keywords, CC, distribution/OS, status, description, attachments, change history<br />
Repository=====<br />
it seems to be a local repository<br />
Release Cycle=====<br />
The roadmap is updated at the beginning of each release cycle.<br />
<br />
Sahana Eden====<br />
Community=====<br />
* Developers: people who develop the software; names and roles do not seem to be defined, unlike Sugar Labs; rather, there seems to be more "how to get started" info here<br />
* Testers: non-technical users who do QA through manual testing; there are links for documenting test cases, as well as links for developers<br />
* Designers: people who work on the user interface<br />
Tracker====<br />
* types: defect/bug, documentation, enhancement, task<br />
* info available for each ticket: ID#, reported by, owned by, priority, milestone, component, version, keywords, CC, due date, launchpad bug, description, attachments, change history<br />
* this is different from Sugar Labs because the tickets are organized into reports, rather than just presenting one large list<br />
Repository====<br />
since this is hosted on github, it is a shared/web repository<br />
Release Cycle====<br />
The roadmap/milestones seems to be based on the completion of features and not a specific date-driven release cycle.<br />
<br />
Part B: Project Evaluation Activity===<br />
[[File:Mifos_Evaluation_Template.xlsx]]<br />
<br />
Part B: FOSS in Courses Planning 1===<br />
Step 3.====<br />
For my undergraduate software engineering course, the motivation is to give students experience working with a large code base, and to get them thinking about the design of software. So I am interested in having the students add functionality to the project (along with corresponding test cases) but also to think about how they’re identifying components, the relationship between those components, etc. <br />
<br />
For my graduate software engineering course, the emphasis is on “what is good code?” so we spend a lot of time reviewing code and figuring out ways to improve it. So the HFOSS-related activities would include conducting code inspections and then refactoring code to improve its design and internal quality, as well as bug fixing and regression testing.<br />
<br />
Step 4.====<br />
For the undergraduate course, the activities would be based on the proposed CS2 assignments from the “50 ways to be a FOSSer” blog. I would have the students look at the existing code and document the design using UML, and also ask them to identify the usage (or attempted usage) of the design patterns we study in class. Then I would have them propose a feature, design the components using appropriate patterns, and then implement and test the feature.<br />
<br />
For the graduate course, I would use some combination of the “Quality & Testing” and “Coding & Style” activities from the same blog. Students would start out by choosing one of the open defects, writing a test case that demonstrates that bug, and then fixing the bug. I would also ask them to create additional test cases for that component using test set adequacy metrics and then fix any other bugs they reveal. Then, once they’re comfortable with the expected functionality, they would conduct a code inspection, document “code smells”, and then refactor the code to improve its quality.<br />
<br />
Part C: Bug Tracker Activity===<br />
Part 1. Bug Reports====<br />
1. Define what each of the column names below indicate. Include the range of possible values for 2-7 below. Feel free to explore beyond the page to find more information.<br />
<br />
1. ID: a unique ID for each bug<br />
<br />
2. Sev: the severity of the bug; normal, minor, major, critical, enhancement, blocker, trivial<br />
<br />
3. Pri: priority; low, normal, high, urgent<br />
<br />
4. OS: operating system; all, Linux, open, Windows, Solaris, Mac, other<br />
<br />
5. Product: which product the bug affects; lots of possible values<br />
<br />
6. Status: current status of the bug; unconfirmed, new, assigned, reopened, need info<br />
<br />
7. Resolution: no possible values listed; maybe a link to a description of how it was resolved?<br />
<br />
8. Summary: summary of the bug<br />
<br />
2. Describe how you discovered the definitions and how did you find the information from above (hint: the advanced search shows the options or the Reports link has a link)? I sorted each category to see the possible options, and then opened up a bug report and read the longer description to see what was there<br />
<br />
3. Identify the order in which the bugs are initially displayed? seems like they're sorted by status<br />
<br />
4. What is the meaning of the shading of some bug reports? hmmm… I can't tell; seems like every other entry is shaded, unless it's an enhancement<br />
<br />
5. What is the meaning of the colors used when describing a bug (red, gray, black)? red is for blocker or critical status; gray is for enhancements<br />
<br />
6. Select a bug that you think that you might be able to fix and look at it more closely (click on the bug number). -- I chose 561837<br />
<br />
1. Identify when the bug was submitted. -- 2008-11-21<br />
<br />
2. Identify if there has been recent discussion about the bug? -- not since 2013-08-14<br />
<br />
3. Is the bug current? -- doesn't seem like it<br />
<br />
4. Is the bug assigned? To whom? -- to At-spi maintainer(s)<br />
<br />
5. Describe what you would need to do to fix the bug. -- it looks like someone created a patch but no one confirmed it, so I guess I'd need to know whether the patch is okay<br />
<br />
7. Repeat the previous step with a different kind of bug. -- I chose 437375<br />
<br />
1. submitted 2007-05-10<br />
<br />
2. no recent discussion since 2011-06-23<br />
<br />
3. doesn't seem current<br />
<br />
4. assigned to ATK maintainer(s)<br />
<br />
5. this bug describes an ambiguity in the doc; I'd need to make sure that the description is unambiguous using the terminology expected by the intended audience<br />
<br />
Part 2. Collective Reports====<br />
<br />
2. How many bug reports were opened in the last week? How many were closed? -- 325 reports opened and 386 reports closed.<br />
<br />
3. What was the general trend last week? Were more bugs opened than closed or vice versa? -- more closed than opened<br />
<br />
4. Who were the top three bug closers? Why is this important to know? -- Jean-François Fortin Tam, Bastien Nocera, Matthias Clasen -- perhaps they are the ones who know the code best<br />
<br />
5. Who were the top three bug reporters? Are these the same as the top three bug closes? What is the overlap in these two lists? -- Jo, Jean-François Fortin Tam, Michael Catanzaro -- not too much overlap except for Jean-Francois<br />
<br />
6. Who are the top three contributors of patches? -- Ray Strode [halfline], Bastien Nocera, Marcos Chavarria Teijeiro<br />
<br />
7. Who are the top three reviewers of patches? What is the overlap between these lists and the bug closers and bug reporters? What is the overlap between patch contributors and patch reviewers? -- Sebastian Dröge (slomo), Florian Müllner, Jonas Danielsson -- there is a little overlap between patch contributors and bug closers, which makes sense because once you patch it, you can mark it closed; not too much overlap between reviewers and contributors, which is to be expected, since the people who contribute a patch should not be reviewing their own work<br />
<br />
10. What other reports can you generate? -- tons!<br />
<br />
<br />
Part C: FOSS in Courses Planning 2===<br />
Part 1.====<br />
For both my undergraduate and graduate courses, I imagine that the FOSS activities would consist of two homework assignments: one in which the students evaluate the existing code, and then another in which they add to the code base or somehow improve the code.<br />
<br />
I can imagine having a lecture around the benefits of FOSS for the undergrads, but I wouldn't think it's necessary for the homework assignments, which are simply focused on "existing code".<br />
<br />
As for a project, we typically do customer-focused apps for our local community, and for undergrads the focus is on developing an app from scratch, but if a group of graduate students was particularly interested in contributing to a FOSS project, we could certainly explore that option. <br />
<br />
Part 2.====<br />
Learning outcomes: For the undergrads, to be able to document the design (e.g. using UML) of existing code, to convert a set of requirements into a design, and to implement and test the code. For the graduate students, to be able to adequately test existing code, to debug code, and to refactor code.<br />
<br />
Pre-requisite knowledge: Aside from the programming language of choice, I don't think there's much in the way of pre-reqs. Part of the challenge, especially for the graduates, would be to figure out the intent of the code as they are working with it.<br />
<br />
Time estimates: It may take quite a while (~20 hours) to identify a project, figure out parts of the code to work with, identify the work that can realistically be done, and then write up the assignment and put together a grading rubric. For the undergrads, if we want to contribute new features to the project, we'd definitely need to coordinate that with the community, particularly as we have 130+ students in that class.<br />
<br />
Input required for community: If we want to add new features, we will likely need to have those approved/vetted. For things like bug fixing and refactoring, though, I suspect the primary input will be coding conventions.<br />
<br />
Assessment: For the undergrads, the documentation of the design of the code can be an individual assignment. If they are to design and implement new features, though, that would probably be in groups, primarily to address issues of scale. I wouldn't want to associate getting the work committed with the grade, though, as that is somewhat out of our control. For the graduates, the assignments (fixing bugs, writing tests, refactoring) could be done in pairs, and I might be more inclined to require that bug fixes or refactoring be committed, since presumably someone in the community would be able to assess their work as "good enough".<br />
<br />
Questions/concerns: The more I think about this, the more concerned I get about issues of scale. My undergrad class has over 130 students; the graduate class has around 80. Documenting the design of the existing code is something that scales, since I wouldn't expect that we'd actually contribute that back to the project. But for the undergrads, even if they work in groups of four, what sort of effort will it take on my part to coordinate 30-something new contributions to existing projects? Will the groups all work on distinct features? How would they be graded? It wouldn't really make sense for multiple groups to work on the exact same feature, since only one implementation would be committed. Likewise, for the graduates, do the 80 students work on fixing 80 different bugs? And then refactor 80 different pieces of code? Again, it wouldn't make sense to have them all refactoring the same piece of code.<br />
<br />
[[Category:POSSE 2014-11]]<br />
[[Category:POSSE 2016-06]]<br />
[[Category:POSSE 2016-11]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Stage_2_ActivitiesStage 2 Activities2018-06-18T21:13:48Z<p>Cmurphy: /* Schedule for POSSE 2018-06 in Philadelphia */</p>
<hr />
<div>__NOTOC__<br />
= Objectives =<br />
<br />
Participants completing the Stage 2 workshop will be able to:<br />
<br />
* Describe the variety of learning activities that student participation in HFOSS projects may include<br />
* Implement HFOSS activities appropriate for a particular curriculum and student population<br />
* Explain challenges and opportunities of student HFOSS participation<br />
* Discuss key aspects of FOSS culture and process <br />
* Use a selection of tools common in HFOSS projects<br />
* Select an HFOSS project well-suited for student participation<br />
* Identify key sources of information for learning about HFOSS<br />
* Identify other participants with similar ideas about applying HFOSS<br />
* Participate in POSSE Stage 3<br />
<br />
== Quick Links == <br />
*[https://drive.google.com/drive/folders/1Wl7HTDmcRNRWQmVVNAeeRHmw2kz-6SM8 Google Drive for Activities]<br />
*[https://pad.riseup.net/p/Intro_A-H Introductions - Last Name A-H]<br />
*[https://pad.riseup.net/p/Intro_I-Z Introductions - Last Name I-Z]<br />
*[https://docs.google.com/document/d/1AX94AXwj-MIOuDGMdQ1ugRmofDlKNJ1FXF8c44OuINI/edit Introductions - if you can't access the Rise-up Pad]<br />
<br />
= Schedule for POSSE 2018-06 in Philadelphia =<br />
<br />
Below is the schedule for the stage 2 workshop activities. <br />
{|border="1"<br />
! Time<br />
! Activity<br />
! Team<br />
|- <br />
|<br />
! Day 1 (Afternoon and Evening)<br />
|<br />
|-<br />
| 1:30 PM<br />
| Leave the hotel for POSSE<br />
| All<br />
|-<br />
| 2:00 <br />
| 1.1 Welcome<br />
* Plan for the day<br />
* Welcome to Philadelphia<br />
* Introducing everyone<br />
* Workshop overview and schedule<br />
| Greg, Lori<br />
|-<br />
| 2:45<br />
| 1.2 HFOSS in Education - (Activity 75 minutes, Slides 15 minutes)<br />
* 50 Ways to be a FOSSer<br />
* Exploration of student contributions <br />
| Chris, Heidi<br />
|-<br />
| 4:15<br />
| Break<br />
| All<br />
|-<br />
| 4:30<br />
| 1.3 HFOSS Process and Tools<br />
* How tools fit and support HFOSS culture<br />
* Upstream Adoption<br />
* Licensing<br />
| Darci, Gina<br />
|-<br />
| 5:00<br />
| GitHub Education<br />
| [http://mozzadrella.me/ Vanessa]<br />
|-<br />
| 5:15<br />
| Dinner - working / social dinner<br />
| All<br />
|-<br />
| 6:15<br />
| 1.4 Git Intro Activity<br />
* [https://github.com/StoneyJackson/git-intro-activity Hands-on exploration] of managing a local repository <br />
| Becka, Stoney<br />
|-<br />
| 8:00<br />
| Return to the hotel<br />
| All<br />
|-<br />
| 8:30<br />
| Social Hour - Optional<br />
| All<br />
|- <br />
|<br />
! Day 2<br />
|<br />
|- <br />
| 7:45<br />
| Leave the hotel for POSSE<br />
| All<br />
|-<br />
| 8:00<br />
| Breakfast<br />
| All<br />
|-<br />
| 8:30<br />
| 2.1 Approach to HFOSS Learning<br />
* POGIL<br />
* Pathways<br />
| Greg, Clif<br />
|-<br />
| 9:15<br />
| 2.2 GitHub Workflow Activity<br />
* [https://github.com/StoneyJackson/github-workflow-activity A common workflow] for HFOSS contribution<br />
| Darci, Stoney<br />
|-<br />
| <br />
| Take Break When Convenient<br />
| All<br />
|-<br />
| 11:00<br />
| 2.3 Understanding Open Source Communities<br />
* Perspective on basic characteristics common in HFOSS communities<br />
** FOSSisms that capture FOSS culture and methods<br />
| Chris, Clif<br />
|-<br />
| 12:15<br />
| Mozilla Open Source Student Network<br />
* [https://opensource.mozilla.community/] <br />
| Christos<br />
|-<br />
| 12:30<br />
| Lunch <br />
| All<br />
|-<br />
| 1:30<br />
| 2.4 HFOSS in the Curriculum Activity (60 minutes)<br />
* Discussion (15 minutes)<br />
** Options for getting started in courses<br />
** HFOSS beyond the curriculum <br />
** Trying to find the right size student project<br />
** Evaluating student work<br />
** Instructional style: mentoring vs. lecturing; instructor as co-learner<br />
| Becka, Clif<br />
|-<br />
| 2:30<br />
| 2.5 Project Evaluation Activity<br />
| Darci, Lori<br />
|-<br />
| 3:15<br />
| Linux Foundation - Open Source Networking<br />
| Trishan<br />
|-<br />
| 3:30<br />
| Break<br />
| All<br />
|-<br />
| 3:45<br />
| 2.6 Planning for HFOSS Participation<br />
* Form groups (based either on courses or HFOSS projects)<br />
* In each group:<br />
** Download and install dev environment for HFOSS project if appropriate<br />
** Identify three things that you would like to get done by the end of POSSE<br />
** Plan a schedule for accomplishing these<br />
| Heidi<br />
|-<br />
| 6:00 <br />
| Dinner - Pietro's, 1714 Walnut St.<br />
| All<br />
|- <br />
|<br />
! Day 3<br />
|<br />
|-<br />
| 7:45<br />
| Leave the hotel (checkout first)<br />
| All<br />
|-<br />
| 8:00<br />
| Breakfast <br />
| All<br />
|-<br />
| 8:30<br />
| 3.1 Understanding POSSE Stage 3<br />
* Experience reports<br />
| Greg, Chris, Becka, Darci<br />
|-<br />
| 9:30 <br />
| <br />
3.2 Sharing HFOSS Learning Activities<br />
* Review of Activity Template<br />
* Group work<br />
| Heidi<br />
|-<br />
| 10:30<br />
| Break<br />
| All<br />
|-<br />
| 10:45<br />
| 3.2 Sharing HFOSS Learning Activities - Continued<br />
| All<br />
|-<br />
| 11:45<br />
| Red Hat University Outreach <br />
| Gina<br />
|-<br />
| 12:00<br />
| Lunch - Lunch Entertainment: [https://drexel.qualtrics.com/jfe/form/SV_72jbRS6I6TsrIyx Evaluation Form] <br />
| All<br />
|-<br />
| 12:45<br />
| 3.2 Sharing HFOSS Learning Activities - Continued<br />
* Groups report back on work done before lunch<br />
* Groups continue to work <br />
| All<br />
|-<br />
| 1:45 <br />
| 3.3 Stage 3 - First Steps<br />
* What will the group do together?<br />
* Plan some initial activities (faculty only or faculty and students)<br />
* Discuss group communication<br />
* Assessment<br />
| Heidi, Clif<br />
|-<br />
| 2:45<br />
| 3.4 Going Forward<br />
* Evaluation form<br />
* Open discussion <br />
* Closing remarks<br />
| Greg<br />
|-<br />
| 3:30<br />
| End - shuttles and taxi to airport<br />
| All<br />
|}<br />
<br />
= Downloads =<br />
<!-- * [https://drive.google.com/open?id=0B92hZzmXFmvQQlZnZG1EdGhSZEk Presentation Materials - Stage 2 - Day 1] --><br />
<!-- <br />
* [https://drive.google.com/drive/folders/0B1g5HGhZ4fOuU3ZIU0pRZkpKOG8 Presentation materials for stage 2]<br />
* [https://github.com/StoneyJackson/CollabDev Stoney's Git and GitHub Activities]<br />
* [https://docs.google.com/presentation/d/1YYi3STtYoMAfSc59bjz46Sqx4tkYgPhCvDKs5W9Lxew/edit?usp=sharing Matt's presentation] on Mozilla's Campus Clubs<br />
--><br />
<br />
<!-- = Shared Files Folder =<br />
<br />
* [https://drive.google.com/drive/folders/0B2rMbpfK2ojueVE3VmlvUUdCOUE?usp=sharing Google Drive folder for team activities] --><br />
<br />
= IRC =<br />
* Server: '''irc.freenode.net'''<br />
* Channel: '''#foss2serve'''<br />
<br />
Standard IRC clients may not work at some workshop locations due to port blockage. If you have problems, please let the team know and try one of the Web-based IRC interfaces below.<br />
<br />
=== Web-based IRC Clients ===<br />
<br />
* http://webchat.freenode.net/ (has a limit from one IP)<br />
* https://kiwiirc.com/client/irc.freenode.net/ <br />
* http://www.mibbit.com/<br />
<br />
== Logs ==<br />
<!-- <br />
* Thursday: <br />
** Minutes: <br />
** Log: <br />
<br />
* Friday: <br />
** Minutes: <br />
** Log: <br />
<br />
* Saturday:<br />
** Minutes:<br />
** Log:<br />
--><br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:POSSE]]</div>Cmurphyhttp://www.foss2serve.org/index.php/User:CmurphyUser:Cmurphy2018-06-17T23:50:03Z<p>Cmurphy: /* Chris Murphy */</p>
<hr />
<div>==Chris Murphy==<br />
<br />
I am an Associate Professor of Practice in the Dept. of Computer & Information Science at the University of Pennsylvania: http://www.seas.upenn.edu/~cdmurphy<br />
<br />
I first attended POSSE in November 2014 and have since attended three more, as well as two POSSE Roundup pre-symposium events at SIGCSE.<br />
<br />
My current interests include online education, student contributions to open source software projects, and how these affect diversity and inclusion within CS.<br />
<br />
Prior to joining Penn in 2010, I completed a PhD in Computer Science at Columbia University, where my research focused on software testing. Before that, I worked as a professional software developer in Boston, San Francisco, and London after earning a BS in Computer Engineering from Boston University.<br />
<br />
Somewhere along the way, I also spent two years teaching English in Seoul, but that's not really part of the narrative hahaha...<br />
<br />
I have occasionally taught a standalone course on open-source software development at Penn, though unfortunately I have not been able to teach it since Fall 2016. A webpage with an overview of the course is available at http://www.seas.upenn.edu/~cdmurphy/foss/ and the full syllabus is [[FOSS Course, UPenn, Murphy|here]]. Other resources not hosted on foss2serve are available at https://github.com/ChrisMurphyOnline/open-source-software-development-course<br />
<br />
I have a few publications and presentations regarding open source software, including:<br />
* [http://www.seas.upenn.edu/~cdmurphy/pubs/Weng-RESPECT2018.pdf "Bridging the Diversity Gap in Computer Science with a Course on Open Source Software"], J. Weng and C. Murphy, In Proc of the 3rd Annual IEEE STCBP Conference on Research on Equity & Sustained Participation in Engineering, Computing, and Technology (RESPECT), Baltimore MD, Feb 2018.<br />
* "Addressing Diversity & Inclusion Issues in Computer Science through Contributions to Free and Open Source Software" (Birds of a Feather session with J. Weng, N. Veilleux, and J. Pearce), 2017 ACM Richard Tapia Celebration of Diversity in Computing, Atlanta GA, Sept 21, 2017. <br />
* "Community Engagement with Free and Open Source Software" (panel moderator), 48th ACM SIGCSE Technical Symposium on Computer Science Education, Seattle WA, Mar 9, 2017. <br />
<br />
You can find out more in [http://www.seas.upenn.edu/~cdmurphy/ChrisMurphy-CV.pdf my CV] and on [https://www.linkedin.com/in/chrismurphyonline my LinkedIn page]!<br />
<br />
==POSSE 11-2014 Stage 1 Activities==<br />
Part A: Intro to IRC, Part 1===<br />
* How do people interact? briefly, but politely, and usually offering to help out or at least make helpful suggestions<br />
* What is the pattern of communication? generally focused on a particular issue: someone raises it and the others try to help out<br />
* Are there any terms that seem to have special meaning? technical terms, of course, but also the commands to MeetBot<br />
* Can you make any other observations? amber does not seem to be a big fan of capitalization and punctuation :-p<br />
<br />
Part A: Intro to IRC, Part 3===<br />
* I observed the #openMRS channel on Tues Oct 14.<br />
* There was a "global notice" that went to all freenode users; I didn't realize it at first, as I thought it was just for the channel users, but I see the difference now.<br />
* There was a conversation between two users in which one was attempting to help the other get the code downloaded and installed. <br />
* The OpenMRSBot occassionally sent messages based on activities in Jira<br />
* At 10am EDT, a user started the daily SCRUM meeting. Users were asked to give updates in order, however two of the three were absent<br />
* I noticed that most of the conversations were between two people, in which they included the other person's nickname at the start of their entry<br />
<br />
Part A: Project Anatomy===<br />
Sugar Labs====<br />
Community=====<br />
* Activity Team: develops and maintains many of the activities; there are 2 coordinators and 13 contributors<br />
* Development Team: build and maintain the core Sugar environment; there is no coordinator and 4 "people" listed; there is no overlap with the Activity team<br />
* Documentation Team: provide the Sugar community with high quality documentation; no coordinator or contributors are listed<br />
Tracker=====<br />
* types: defects and enhancements<br />
* info available for each ticket: ID#, reported by, owned by, priority, milestone, component, version, severity, keywords, CC, distribution/OS, status, description, attachments, change history<br />
Repository=====<br />
it seems to be a local repository<br />
Release Cycle=====<br />
The roadmap is updated at the beginning of each release cycle.<br />
<br />
Sahana Eden====<br />
Community=====<br />
* Developers: people who develop the software; names and roles do not seem to be defined, unlike Sugar Labs; rather, there seems to be more "how to get started" info here<br />
* Testers: non-technical users who do QA through manual testing; there are links for documenting test cases, as well as links for developers<br />
* Designers: people who work on the user interface<br />
Tracker====<br />
* types: defect/bug, documentation, enhancement, task<br />
* info available for each ticket: ID#, reported by, owned by, priority, milestone, component, version, keywords, CC, due date, launchpad bug, description, attachments, change history<br />
* this is different from Sugar Labs because the tickets are organized into reports, rather than just presenting one large list<br />
Repository====<br />
since this is hosted on github, it is a shared/web repository<br />
Release Cycle====<br />
The roadmap/milestones seems to be based on the completion of features and not a specific date-driven release cycle.<br />
<br />
Part B: Project Evaluation Activity===<br />
[[File:Mifos_Evaluation_Template.xlsx]]<br />
<br />
Part B: FOSS in Courses Planning 1===<br />
Step 3.====<br />
For my undergraduate software engineering course, the motivation is to give students experience working with a large code base, and to get them thinking about the design of software. So I am interested in having the students add functionality to the project (along with corresponding test cases) but also to think about how they’re identifying components, the relationship between those components, etc. <br />
<br />
For my graduate software engineering course, the emphasis is on “what is good code?” so we spend a lot of time reviewing code and figuring out ways to improve it. So the HFOSS-related activities would include conducting code inspections and then refactoring code to improve its design and internal quality, as well as bug fixing and regression testing.<br />
<br />
Step 4.====<br />
For the undergraduate course, the activities would be based on the proposed CS2 assignments from the “50 ways to be a FOSSer” blog. I would have the students look at the existing code and document the design using UML, and also ask them to identify the usage (or attempted usage) of the design patterns we study in class. Then I would have them propose a feature, design the components using appropriate patterns, and then implement and test the feature.<br />
<br />
For the graduate course, I would use some combination of the “Quality & Testing” and “Coding & Style” activities from the same blog. Students would start out by choosing one of the open defects, writing a test case that demonstrates that bug, and then fixing the bug. I would also ask them to create additional test cases for that component using test set adequacy metrics and then fix any other bugs they reveal. Then, once they’re comfortable with the expected functionality, they would conduct a code inspection, document “code smells”, and then refactor the code to improve its quality.<br />
<br />
Part C: Bug Tracker Activity===<br />
Part 1. Bug Reports====<br />
1. Define what each of the column names below indicate. Include the range of possible values for 2-7 below. Feel free to explore beyond the page to find more information.<br />
<br />
1. ID: a unique ID for each bug<br />
<br />
2. Sev: the severity of the bug; normal, minor, major, critical, enhancement, blocker, trivial<br />
<br />
3. Pri: priority; low, normal, high, urgent<br />
<br />
4. OS: operating system; all, Linux, open, Windows, Solaris, Mac, other<br />
<br />
5. Product: which product the bug affects; lots of possible values<br />
<br />
6. Status: current status of the bug; unconfirmed, new, assigned, reopened, need info<br />
<br />
7. Resolution: no possible values listed; maybe a link to a description of how it was resolved?<br />
<br />
8. Summary: summary of the bug<br />
<br />
2. Describe how you discovered the definitions and how did you find the information from above (hint: the advanced search shows the options or the Reports link has a link)? I sorted each category to see the possible options, and then opened up a bug report and read the longer description to see what was there<br />
<br />
3. Identify the order in which the bugs are initially displayed? seems like they're sorted by status<br />
<br />
4. What is the meaning of the shading of some bug reports? hmmm… I can't tell; seems like every other entry is shaded, unless it's an enhancement<br />
<br />
5. What is the meaning of the colors used when describing a bug (red, gray, black)? red is for blocker or critical status; gray is for enhancements<br />
<br />
6. Select a bug that you think that you might be able to fix and look at it more closely (click on the bug number). -- I chose 561837<br />
<br />
1. Identify when the bug was submitted. -- 2008-11-21<br />
<br />
2. Identify if there has been recent discussion about the bug? -- not since 2013-08-14<br />
<br />
3. Is the bug current? -- doesn't seem like it<br />
<br />
4. Is the bug assigned? To whom? -- to At-spi maintainer(s)<br />
<br />
5. Describe what you would need to do to fix the bug. -- it looks like someone created a patch but no one confirmed it, so I guess I'd need to know whether the patch is okay<br />
<br />
7. Repeat the previous step with a different kind of bug. -- I chose 437375<br />
<br />
1. submitted 2007-05-10<br />
<br />
2. no recent discussion since 2011-06-23<br />
<br />
3. doesn't seem current<br />
<br />
4. assigned to ATK maintainer(s)<br />
<br />
5. this bug describes an ambiguity in the doc; I'd need to make sure that the description is unambiguous using the terminology expected by the intended audience<br />
<br />
Part 2. Collective Reports====<br />
<br />
2. How many bug reports were opened in the last week? How many were closed? -- 325 reports opened and 386 reports closed.<br />
<br />
3. What was the general trend last week? Were more bugs opened than closed or vice versa? -- more closed than opened<br />
<br />
4. Who were the top three bug closers? Why is this important to know? -- Jean-François Fortin Tam, Bastien Nocera, Matthias Clasen -- perhaps they are the ones who know the code best<br />
<br />
5. Who were the top three bug reporters? Are these the same as the top three bug closes? What is the overlap in these two lists? -- Jo, Jean-François Fortin Tam, Michael Catanzaro -- not too much overlap except for Jean-Francois<br />
<br />
6. Who are the top three contributors of patches? -- Ray Strode [halfline], Bastien Nocera, Marcos Chavarria Teijeiro<br />
<br />
7. Who are the top three reviewers of patches? What is the overlap between these lists and the bug closers and bug reporters? What is the overlap between patch contributors and patch reviewers? -- Sebastian Dröge (slomo), Florian Müllner, Jonas Danielsson -- there is a little overlap between patch contributors and bug closers, which makes sense because once you patch it, you can mark it closed; not too much overlap between reviewers and contributors, which is to be expected, since the people who contribute a patch should not be reviewing their own work<br />
<br />
10. What other reports can you generate? -- tons!<br />
<br />
<br />
Part C: FOSS in Courses Planning 2===<br />
Part 1.====<br />
For both my undergraduate and graduate courses, I imagine that the FOSS activities would consist of two homework assignments: one in which the students evaluate the existing code, and then another in which they add to the code base or somehow improve the code.<br />
<br />
I can imagine having a lecture around the benefits of FOSS for the undergrads, but I wouldn't think it's necessary for the homework assignments, which are simply focused on "existing code".<br />
<br />
As for a project, we typically do customer-focused apps for our local community, and for undergrads the focus is on developing an app from scratch, but if a group of graduate students was particularly interested in contributing to a FOSS project, we could certainly explore that option. <br />
<br />
Part 2.====<br />
Learning outcomes: For the undergrads, to be able to document the design (e.g. using UML) of existing code, to convert a set of requirements into a design, and to implement and test the code. For the graduate students, to be able to adequately test existing code, to debug code, and to refactor code.<br />
<br />
Pre-requisite knowledge: Aside from the programming language of choice, I don't think there's much in the way of pre-reqs. Part of the challenge, especially for the graduates, would be to figure out the intent of the code as they are working with it.<br />
<br />
Time estimates: It may take quite a while (~20 hours) to identify a project, figure out parts of the code to work with, identify the work that can realistically be done, and then write up the assignment and put together a grading rubric. For the undergrads, if we want to contribute new features to the project, we'd definitely need to coordinate that with the community, particularly as we have 130+ students in that class.<br />
<br />
Input required for community: If we want to add new features, we will likely need to have those approved/vetted. For things like bug fixing and refactoring, though, I suspect the primary input will be coding conventions.<br />
<br />
Assessment: For the undergrads, the documentation of the design of the code can be an individual assignment. If they are to design and implement new features, though, that would probably be in groups, primarily to address issues of scale. I wouldn't want to associate getting the work committed with the grade, though, as that is somewhat out of our control. For the graduates, the assignments (fixing bugs, writing tests, refactoring) could be done in pairs, and I might be more inclined to require that bug fixes or refactoring be committed, since presumably someone in the community would be able to assess their work as "good enough".<br />
<br />
Questions/concerns: The more I think about this, the more concerned I get about issues of scale. My undergrad class has over 130 students; the graduate class has around 80. Documenting the design of the existing code is something that scales, since I wouldn't expect that we'd actually contribute that back to the project. But for the undergrads, even if they work in groups of four, what sort of effort will it take on my part to coordinate 30-something new contributions to existing projects? Will the groups all work on distinct features? How would they be graded? It wouldn't really make sense for multiple groups to work on the exact same feature, since only one implementation would be committed. Likewise, for the graduates, do the 80 students work on fixing 80 different bugs? And then refactor 80 different pieces of code? Again, it wouldn't make sense to have them all refactoring the same piece of code.<br />
<br />
[[Category:POSSE 2014-11]]<br />
[[Category:POSSE 2016-06]]<br />
[[Category:POSSE 2016-11]]</div>Cmurphyhttp://www.foss2serve.org/index.php/User:CmurphyUser:Cmurphy2018-06-17T23:48:43Z<p>Cmurphy: /* POSSE 11-2014 Stage 1 Activities */</p>
<hr />
<div>==Chris Murphy==<br />
<br />
I am an Associate Professor of Practice in the Dept. of Computer & Information Science at the University of Pennsylvania: http://www.seas.upenn.edu/~cdmurphy<br />
<br />
I first attended POSSE in November 2014 and have since attended three more, as well as two POSSE Roundup pre-symposium events at SIGCSE.<br />
<br />
My current interests include online education, student contributions to open source software projects, and how these affect diversity and inclusion within CS.<br />
<br />
Prior to joining Penn in 2010, I completed a PhD in Computer Science at Columbia University, where my research focused on software testing. Before that, I worked as a professional software developer in Boston, San Francisco, and London after earning a BS in Computer Engineering from Boston University.<br />
<br />
Somewhere along the way, I also spent two years teaching English in Seoul, but that's not really part of the narrative hahaha...<br />
<br />
I have occasionally taught a standalone course on open-source software development at Penn, though unfortunately I have not been able to teach it since Fall 2016. A webpage with an overview of the course is available at http://www.seas.upenn.edu/~cdmurphy/foss/ and the full syllabus is [[FOSS Course, UPenn, Murphy|here]]. Other resources not hosted on foss2serve are available at https://github.com/ChrisMurphyOnline/open-source-software-development-course<br />
<br />
I have a few publications and presentations regarding open source software, including:<br />
* [http://www.seas.upenn.edu/~cdmurphy/pubs/Weng-RESPECT2018.pdf "Bridging the Diversity Gap in Computer Science with a Course on Open Source Software"], J. Weng and C. Murphy, In Proc of the 3rd Annual IEEE STCBP Conference on Research on Equity & Sustained Participation in Engineering, Computing, and Technology (RESPECT), Baltimore MD, Feb 2018.<br />
* "Addressing Diversity & Inclusion Issues in Computer Science through Contributions to Free and Open Source Software" (Birds of a Feather session with J. Weng, N. Veilleux, and J. Pearce) 2017 ACM Richard Tapia Celebration of Diversity in Computing, Atlanta GA, Sept 21, 2017. <br />
* "Community Engagement with Free and Open Source Software" (panel moderator), 48th ACM SIGCSE Technical Symposium on Computer Science Education, Seattle WA, Mar 9, 2017. <br />
<br />
You can find out more in [http://www.seas.upenn.edu/~cdmurphy/ChrisMurphy-CV.pdf my CV] and on [https://www.linkedin.com/in/chrismurphyonline my LinkedIn page]!<br />
<br />
==POSSE 11-2014 Stage 1 Activities==<br />
Part A: Intro to IRC, Part 1===<br />
* How do people interact? briefly, but politely, and usually offering to help out or at least make helpful suggestions<br />
* What is the pattern of communication? generally focused on a particular issue: someone raises it and the others try to help out<br />
* Are there any terms that seem to have special meaning? technical terms, of course, but also the commands to MeetBot<br />
* Can you make any other observations? amber does not seem to be a big fan of capitalization and punctuation :-p<br />
<br />
Part A: Intro to IRC, Part 3===<br />
* I observed the #openMRS channel on Tues Oct 14.<br />
* There was a "global notice" that went to all freenode users; I didn't realize it at first, as I thought it was just for the channel users, but I see the difference now.<br />
* There was a conversation between two users in which one was attempting to help the other get the code downloaded and installed. <br />
* The OpenMRSBot occassionally sent messages based on activities in Jira<br />
* At 10am EDT, a user started the daily SCRUM meeting. Users were asked to give updates in order, however two of the three were absent<br />
* I noticed that most of the conversations were between two people, in which they included the other person's nickname at the start of their entry<br />
<br />
Part A: Project Anatomy===<br />
Sugar Labs====<br />
Community=====<br />
* Activity Team: develops and maintains many of the activities; there are 2 coordinators and 13 contributors<br />
* Development Team: build and maintain the core Sugar environment; there is no coordinator and 4 "people" listed; there is no overlap with the Activity team<br />
* Documentation Team: provide the Sugar community with high quality documentation; no coordinator or contributors are listed<br />
Tracker=====<br />
* types: defects and enhancements<br />
* info available for each ticket: ID#, reported by, owned by, priority, milestone, component, version, severity, keywords, CC, distribution/OS, status, description, attachments, change history<br />
Repository=====<br />
it seems to be a local repository<br />
Release Cycle=====<br />
The roadmap is updated at the beginning of each release cycle.<br />
<br />
Sahana Eden====<br />
Community=====<br />
* Developers: people who develop the software; names and roles do not seem to be defined, unlike Sugar Labs; rather, there seems to be more "how to get started" info here<br />
* Testers: non-technical users who do QA through manual testing; there are links for documenting test cases, as well as links for developers<br />
* Designers: people who work on the user interface<br />
Tracker====<br />
* types: defect/bug, documentation, enhancement, task<br />
* info available for each ticket: ID#, reported by, owned by, priority, milestone, component, version, keywords, CC, due date, launchpad bug, description, attachments, change history<br />
* this is different from Sugar Labs because the tickets are organized into reports, rather than just presenting one large list<br />
Repository====<br />
since this is hosted on github, it is a shared/web repository<br />
Release Cycle====<br />
The roadmap/milestones seems to be based on the completion of features and not a specific date-driven release cycle.<br />
<br />
Part B: Project Evaluation Activity===<br />
[[File:Mifos_Evaluation_Template.xlsx]]<br />
<br />
Part B: FOSS in Courses Planning 1===<br />
Step 3.====<br />
For my undergraduate software engineering course, the motivation is to give students experience working with a large code base, and to get them thinking about the design of software. So I am interested in having the students add functionality to the project (along with corresponding test cases) but also to think about how they’re identifying components, the relationship between those components, etc. <br />
<br />
For my graduate software engineering course, the emphasis is on “what is good code?” so we spend a lot of time reviewing code and figuring out ways to improve it. So the HFOSS-related activities would include conducting code inspections and then refactoring code to improve its design and internal quality, as well as bug fixing and regression testing.<br />
<br />
Step 4.====<br />
For the undergraduate course, the activities would be based on the proposed CS2 assignments from the “50 ways to be a FOSSer” blog. I would have the students look at the existing code and document the design using UML, and also ask them to identify the usage (or attempted usage) of the design patterns we study in class. Then I would have them propose a feature, design the components using appropriate patterns, and then implement and test the feature.<br />
<br />
For the graduate course, I would use some combination of the “Quality & Testing” and “Coding & Style” activities from the same blog. Students would start out by choosing one of the open defects, writing a test case that demonstrates that bug, and then fixing the bug. I would also ask them to create additional test cases for that component using test set adequacy metrics and then fix any other bugs they reveal. Then, once they’re comfortable with the expected functionality, they would conduct a code inspection, document “code smells”, and then refactor the code to improve its quality.<br />
<br />
Part C: Bug Tracker Activity===<br />
Part 1. Bug Reports====<br />
1. Define what each of the column names below indicate. Include the range of possible values for 2-7 below. Feel free to explore beyond the page to find more information.<br />
<br />
1. ID: a unique ID for each bug<br />
<br />
2. Sev: the severity of the bug; normal, minor, major, critical, enhancement, blocker, trivial<br />
<br />
3. Pri: priority; low, normal, high, urgent<br />
<br />
4. OS: operating system; all, Linux, open, Windows, Solaris, Mac, other<br />
<br />
5. Product: which product the bug affects; lots of possible values<br />
<br />
6. Status: current status of the bug; unconfirmed, new, assigned, reopened, need info<br />
<br />
7. Resolution: no possible values listed; maybe a link to a description of how it was resolved?<br />
<br />
8. Summary: summary of the bug<br />
<br />
2. Describe how you discovered the definitions and how did you find the information from above (hint: the advanced search shows the options or the Reports link has a link)? I sorted each category to see the possible options, and then opened up a bug report and read the longer description to see what was there<br />
<br />
3. Identify the order in which the bugs are initially displayed? seems like they're sorted by status<br />
<br />
4. What is the meaning of the shading of some bug reports? hmmm… I can't tell; seems like every other entry is shaded, unless it's an enhancement<br />
<br />
5. What is the meaning of the colors used when describing a bug (red, gray, black)? red is for blocker or critical status; gray is for enhancements<br />
<br />
6. Select a bug that you think that you might be able to fix and look at it more closely (click on the bug number). -- I chose 561837<br />
<br />
1. Identify when the bug was submitted. -- 2008-11-21<br />
<br />
2. Identify if there has been recent discussion about the bug? -- not since 2013-08-14<br />
<br />
3. Is the bug current? -- doesn't seem like it<br />
<br />
4. Is the bug assigned? To whom? -- to At-spi maintainer(s)<br />
<br />
5. Describe what you would need to do to fix the bug. -- it looks like someone created a patch but no one confirmed it, so I guess I'd need to know whether the patch is okay<br />
<br />
7. Repeat the previous step with a different kind of bug. -- I chose 437375<br />
<br />
1. submitted 2007-05-10<br />
<br />
2. no recent discussion since 2011-06-23<br />
<br />
3. doesn't seem current<br />
<br />
4. assigned to ATK maintainer(s)<br />
<br />
5. this bug describes an ambiguity in the doc; I'd need to make sure that the description is unambiguous using the terminology expected by the intended audience<br />
<br />
Part 2. Collective Reports====<br />
<br />
2. How many bug reports were opened in the last week? How many were closed? -- 325 reports opened and 386 reports closed.<br />
<br />
3. What was the general trend last week? Were more bugs opened than closed or vice versa? -- more closed than opened<br />
<br />
4. Who were the top three bug closers? Why is this important to know? -- Jean-François Fortin Tam, Bastien Nocera, Matthias Clasen -- perhaps they are the ones who know the code best<br />
<br />
5. Who were the top three bug reporters? Are these the same as the top three bug closes? What is the overlap in these two lists? -- Jo, Jean-François Fortin Tam, Michael Catanzaro -- not too much overlap except for Jean-Francois<br />
<br />
6. Who are the top three contributors of patches? -- Ray Strode [halfline], Bastien Nocera, Marcos Chavarria Teijeiro<br />
<br />
7. Who are the top three reviewers of patches? What is the overlap between these lists and the bug closers and bug reporters? What is the overlap between patch contributors and patch reviewers? -- Sebastian Dröge (slomo), Florian Müllner, Jonas Danielsson -- there is a little overlap between patch contributors and bug closers, which makes sense because once you patch it, you can mark it closed; not too much overlap between reviewers and contributors, which is to be expected, since the people who contribute a patch should not be reviewing their own work<br />
<br />
10. What other reports can you generate? -- tons!<br />
<br />
<br />
Part C: FOSS in Courses Planning 2===<br />
Part 1.====<br />
For both my undergraduate and graduate courses, I imagine that the FOSS activities would consist of two homework assignments: one in which the students evaluate the existing code, and then another in which they add to the code base or somehow improve the code.<br />
<br />
I can imagine having a lecture around the benefits of FOSS for the undergrads, but I wouldn't think it's necessary for the homework assignments, which are simply focused on "existing code".<br />
<br />
As for a project, we typically do customer-focused apps for our local community, and for undergrads the focus is on developing an app from scratch, but if a group of graduate students was particularly interested in contributing to a FOSS project, we could certainly explore that option. <br />
<br />
Part 2.====<br />
Learning outcomes: For the undergrads, to be able to document the design (e.g. using UML) of existing code, to convert a set of requirements into a design, and to implement and test the code. For the graduate students, to be able to adequately test existing code, to debug code, and to refactor code.<br />
<br />
Pre-requisite knowledge: Aside from the programming language of choice, I don't think there's much in the way of pre-reqs. Part of the challenge, especially for the graduates, would be to figure out the intent of the code as they are working with it.<br />
<br />
Time estimates: It may take quite a while (~20 hours) to identify a project, figure out parts of the code to work with, identify the work that can realistically be done, and then write up the assignment and put together a grading rubric. For the undergrads, if we want to contribute new features to the project, we'd definitely need to coordinate that with the community, particularly as we have 130+ students in that class.<br />
<br />
Input required for community: If we want to add new features, we will likely need to have those approved/vetted. For things like bug fixing and refactoring, though, I suspect the primary input will be coding conventions.<br />
<br />
Assessment: For the undergrads, the documentation of the design of the code can be an individual assignment. If they are to design and implement new features, though, that would probably be in groups, primarily to address issues of scale. I wouldn't want to associate getting the work committed with the grade, though, as that is somewhat out of our control. For the graduates, the assignments (fixing bugs, writing tests, refactoring) could be done in pairs, and I might be more inclined to require that bug fixes or refactoring be committed, since presumably someone in the community would be able to assess their work as "good enough".<br />
<br />
Questions/concerns: The more I think about this, the more concerned I get about issues of scale. My undergrad class has over 130 students; the graduate class has around 80. Documenting the design of the existing code is something that scales, since I wouldn't expect that we'd actually contribute that back to the project. But for the undergrads, even if they work in groups of four, what sort of effort will it take on my part to coordinate 30-something new contributions to existing projects? Will the groups all work on distinct features? How would they be graded? It wouldn't really make sense for multiple groups to work on the exact same feature, since only one implementation would be committed. Likewise, for the graduates, do the 80 students work on fixing 80 different bugs? And then refactor 80 different pieces of code? Again, it wouldn't make sense to have them all refactoring the same piece of code.<br />
<br />
[[Category:POSSE 2014-11]]<br />
[[Category:POSSE 2016-06]]<br />
[[Category:POSSE 2016-11]]</div>Cmurphyhttp://www.foss2serve.org/index.php/User:CmurphyUser:Cmurphy2018-06-17T23:46:54Z<p>Cmurphy: /* Chris Murphy */</p>
<hr />
<div>==Chris Murphy==<br />
<br />
I am an Associate Professor of Practice in the Dept. of Computer & Information Science at the University of Pennsylvania: http://www.seas.upenn.edu/~cdmurphy<br />
<br />
I first attended POSSE in November 2014 and have since attended three more, as well as two POSSE Roundup pre-symposium events at SIGCSE.<br />
<br />
My current interests include online education, student contributions to open source software projects, and how these affect diversity and inclusion within CS.<br />
<br />
Prior to joining Penn in 2010, I completed a PhD in Computer Science at Columbia University, where my research focused on software testing. Before that, I worked as a professional software developer in Boston, San Francisco, and London after earning a BS in Computer Engineering from Boston University.<br />
<br />
Somewhere along the way, I also spent two years teaching English in Seoul, but that's not really part of the narrative hahaha...<br />
<br />
I have occasionally taught a standalone course on open-source software development at Penn, though unfortunately I have not been able to teach it since Fall 2016. A webpage with an overview of the course is available at http://www.seas.upenn.edu/~cdmurphy/foss/ and the full syllabus is [[FOSS Course, UPenn, Murphy|here]]. Other resources not hosted on foss2serve are available at https://github.com/ChrisMurphyOnline/open-source-software-development-course<br />
<br />
I have a few publications and presentations regarding open source software, including:<br />
* [http://www.seas.upenn.edu/~cdmurphy/pubs/Weng-RESPECT2018.pdf "Bridging the Diversity Gap in Computer Science with a Course on Open Source Software"], J. Weng and C. Murphy, In Proc of the 3rd Annual IEEE STCBP Conference on Research on Equity & Sustained Participation in Engineering, Computing, and Technology (RESPECT), Baltimore MD, Feb 2018.<br />
* "Addressing Diversity & Inclusion Issues in Computer Science through Contributions to Free and Open Source Software" (Birds of a Feather session with J. Weng, N. Veilleux, and J. Pearce) 2017 ACM Richard Tapia Celebration of Diversity in Computing, Atlanta GA, Sept 21, 2017. <br />
* "Community Engagement with Free and Open Source Software" (panel moderator), 48th ACM SIGCSE Technical Symposium on Computer Science Education, Seattle WA, Mar 9, 2017. <br />
<br />
You can find out more in [http://www.seas.upenn.edu/~cdmurphy/ChrisMurphy-CV.pdf my CV] and on [https://www.linkedin.com/in/chrismurphyonline my LinkedIn page]!<br />
<br />
==POSSE 11-2014 Stage 1 Activities==<br />
===Part A: Intro to IRC, Part 1===<br />
* How do people interact? briefly, but politely, and usually offering to help out or at least make helpful suggestions<br />
* What is the pattern of communication? generally focused on a particular issue: someone raises it and the others try to help out<br />
* Are there any terms that seem to have special meaning? technical terms, of course, but also the commands to MeetBot<br />
* Can you make any other observations? amber does not seem to be a big fan of capitalization and punctuation :-p<br />
<br />
===Part A: Intro to IRC, Part 3===<br />
* I observed the #openMRS channel on Tues Oct 14.<br />
* There was a "global notice" that went to all freenode users; I didn't realize it at first, as I thought it was just for the channel users, but I see the difference now.<br />
* There was a conversation between two users in which one was attempting to help the other get the code downloaded and installed. <br />
* The OpenMRSBot occassionally sent messages based on activities in Jira<br />
* At 10am EDT, a user started the daily SCRUM meeting. Users were asked to give updates in order, however two of the three were absent<br />
* I noticed that most of the conversations were between two people, in which they included the other person's nickname at the start of their entry<br />
<br />
===Part A: Project Anatomy===<br />
====Sugar Labs====<br />
=====Community=====<br />
* Activity Team: develops and maintains many of the activities; there are 2 coordinators and 13 contributors<br />
* Development Team: build and maintain the core Sugar environment; there is no coordinator and 4 "people" listed; there is no overlap with the Activity team<br />
* Documentation Team: provide the Sugar community with high quality documentation; no coordinator or contributors are listed<br />
=====Tracker=====<br />
* types: defects and enhancements<br />
* info available for each ticket: ID#, reported by, owned by, priority, milestone, component, version, severity, keywords, CC, distribution/OS, status, description, attachments, change history<br />
=====Repository=====<br />
it seems to be a local repository<br />
=====Release Cycle=====<br />
The roadmap is updated at the beginning of each release cycle.<br />
<br />
====Sahana Eden====<br />
=====Community=====<br />
* Developers: people who develop the software; names and roles do not seem to be defined, unlike Sugar Labs; rather, there seems to be more "how to get started" info here<br />
* Testers: non-technical users who do QA through manual testing; there are links for documenting test cases, as well as links for developers<br />
* Designers: people who work on the user interface<br />
====Tracker====<br />
* types: defect/bug, documentation, enhancement, task<br />
* info available for each ticket: ID#, reported by, owned by, priority, milestone, component, version, keywords, CC, due date, launchpad bug, description, attachments, change history<br />
* this is different from Sugar Labs because the tickets are organized into reports, rather than just presenting one large list<br />
====Repository====<br />
since this is hosted on github, it is a shared/web repository<br />
====Release Cycle====<br />
The roadmap/milestones seems to be based on the completion of features and not a specific date-driven release cycle.<br />
<br />
===Part B: Project Evaluation Activity===<br />
[[File:Mifos_Evaluation_Template.xlsx]]<br />
<br />
===Part B: FOSS in Courses Planning 1===<br />
====Step 3.====<br />
For my undergraduate software engineering course, the motivation is to give students experience working with a large code base, and to get them thinking about the design of software. So I am interested in having the students add functionality to the project (along with corresponding test cases) but also to think about how they’re identifying components, the relationship between those components, etc. <br />
<br />
For my graduate software engineering course, the emphasis is on “what is good code?” so we spend a lot of time reviewing code and figuring out ways to improve it. So the HFOSS-related activities would include conducting code inspections and then refactoring code to improve its design and internal quality, as well as bug fixing and regression testing.<br />
<br />
====Step 4.====<br />
For the undergraduate course, the activities would be based on the proposed CS2 assignments from the “50 ways to be a FOSSer” blog. I would have the students look at the existing code and document the design using UML, and also ask them to identify the usage (or attempted usage) of the design patterns we study in class. Then I would have them propose a feature, design the components using appropriate patterns, and then implement and test the feature.<br />
<br />
For the graduate course, I would use some combination of the “Quality & Testing” and “Coding & Style” activities from the same blog. Students would start out by choosing one of the open defects, writing a test case that demonstrates that bug, and then fixing the bug. I would also ask them to create additional test cases for that component using test set adequacy metrics and then fix any other bugs they reveal. Then, once they’re comfortable with the expected functionality, they would conduct a code inspection, document “code smells”, and then refactor the code to improve its quality.<br />
<br />
===Part C: Bug Tracker Activity===<br />
====Part 1. Bug Reports====<br />
1. Define what each of the column names below indicate. Include the range of possible values for 2-7 below. Feel free to explore beyond the page to find more information.<br />
<br />
1. ID: a unique ID for each bug<br />
<br />
2. Sev: the severity of the bug; normal, minor, major, critical, enhancement, blocker, trivial<br />
<br />
3. Pri: priority; low, normal, high, urgent<br />
<br />
4. OS: operating system; all, Linux, open, Windows, Solaris, Mac, other<br />
<br />
5. Product: which product the bug affects; lots of possible values<br />
<br />
6. Status: current status of the bug; unconfirmed, new, assigned, reopened, need info<br />
<br />
7. Resolution: no possible values listed; maybe a link to a description of how it was resolved?<br />
<br />
8. Summary: summary of the bug<br />
<br />
2. Describe how you discovered the definitions and how did you find the information from above (hint: the advanced search shows the options or the Reports link has a link)? I sorted each category to see the possible options, and then opened up a bug report and read the longer description to see what was there<br />
<br />
3. Identify the order in which the bugs are initially displayed? seems like they're sorted by status<br />
<br />
4. What is the meaning of the shading of some bug reports? hmmm… I can't tell; seems like every other entry is shaded, unless it's an enhancement<br />
<br />
5. What is the meaning of the colors used when describing a bug (red, gray, black)? red is for blocker or critical status; gray is for enhancements<br />
<br />
6. Select a bug that you think that you might be able to fix and look at it more closely (click on the bug number). -- I chose 561837<br />
<br />
1. Identify when the bug was submitted. -- 2008-11-21<br />
<br />
2. Identify if there has been recent discussion about the bug? -- not since 2013-08-14<br />
<br />
3. Is the bug current? -- doesn't seem like it<br />
<br />
4. Is the bug assigned? To whom? -- to At-spi maintainer(s)<br />
<br />
5. Describe what you would need to do to fix the bug. -- it looks like someone created a patch but no one confirmed it, so I guess I'd need to know whether the patch is okay<br />
<br />
7. Repeat the previous step with a different kind of bug. -- I chose 437375<br />
<br />
1. submitted 2007-05-10<br />
<br />
2. no recent discussion since 2011-06-23<br />
<br />
3. doesn't seem current<br />
<br />
4. assigned to ATK maintainer(s)<br />
<br />
5. this bug describes an ambiguity in the doc; I'd need to make sure that the description is unambiguous using the terminology expected by the intended audience<br />
<br />
====Part 2. Collective Reports====<br />
<br />
2. How many bug reports were opened in the last week? How many were closed? -- 325 reports opened and 386 reports closed.<br />
<br />
3. What was the general trend last week? Were more bugs opened than closed or vice versa? -- more closed than opened<br />
<br />
4. Who were the top three bug closers? Why is this important to know? -- Jean-François Fortin Tam, Bastien Nocera, Matthias Clasen -- perhaps they are the ones who know the code best<br />
<br />
5. Who were the top three bug reporters? Are these the same as the top three bug closes? What is the overlap in these two lists? -- Jo, Jean-François Fortin Tam, Michael Catanzaro -- not too much overlap except for Jean-Francois<br />
<br />
6. Who are the top three contributors of patches? -- Ray Strode [halfline], Bastien Nocera, Marcos Chavarria Teijeiro<br />
<br />
7. Who are the top three reviewers of patches? What is the overlap between these lists and the bug closers and bug reporters? What is the overlap between patch contributors and patch reviewers? -- Sebastian Dröge (slomo), Florian Müllner, Jonas Danielsson -- there is a little overlap between patch contributors and bug closers, which makes sense because once you patch it, you can mark it closed; not too much overlap between reviewers and contributors, which is to be expected, since the people who contribute a patch should not be reviewing their own work<br />
<br />
10. What other reports can you generate? -- tons!<br />
<br />
<br />
===Part C: FOSS in Courses Planning 2===<br />
====Part 1.====<br />
For both my undergraduate and graduate courses, I imagine that the FOSS activities would consist of two homework assignments: one in which the students evaluate the existing code, and then another in which they add to the code base or somehow improve the code.<br />
<br />
I can imagine having a lecture around the benefits of FOSS for the undergrads, but I wouldn't think it's necessary for the homework assignments, which are simply focused on "existing code".<br />
<br />
As for a project, we typically do customer-focused apps for our local community, and for undergrads the focus is on developing an app from scratch, but if a group of graduate students was particularly interested in contributing to a FOSS project, we could certainly explore that option. <br />
<br />
====Part 2.====<br />
Learning outcomes: For the undergrads, to be able to document the design (e.g. using UML) of existing code, to convert a set of requirements into a design, and to implement and test the code. For the graduate students, to be able to adequately test existing code, to debug code, and to refactor code.<br />
<br />
Pre-requisite knowledge: Aside from the programming language of choice, I don't think there's much in the way of pre-reqs. Part of the challenge, especially for the graduates, would be to figure out the intent of the code as they are working with it.<br />
<br />
Time estimates: It may take quite a while (~20 hours) to identify a project, figure out parts of the code to work with, identify the work that can realistically be done, and then write up the assignment and put together a grading rubric. For the undergrads, if we want to contribute new features to the project, we'd definitely need to coordinate that with the community, particularly as we have 130+ students in that class.<br />
<br />
Input required for community: If we want to add new features, we will likely need to have those approved/vetted. For things like bug fixing and refactoring, though, I suspect the primary input will be coding conventions.<br />
<br />
Assessment: For the undergrads, the documentation of the design of the code can be an individual assignment. If they are to design and implement new features, though, that would probably be in groups, primarily to address issues of scale. I wouldn't want to associate getting the work committed with the grade, though, as that is somewhat out of our control. For the graduates, the assignments (fixing bugs, writing tests, refactoring) could be done in pairs, and I might be more inclined to require that bug fixes or refactoring be committed, since presumably someone in the community would be able to assess their work as "good enough".<br />
<br />
Questions/concerns: The more I think about this, the more concerned I get about issues of scale. My undergrad class has over 130 students; the graduate class has around 80. Documenting the design of the existing code is something that scales, since I wouldn't expect that we'd actually contribute that back to the project. But for the undergrads, even if they work in groups of four, what sort of effort will it take on my part to coordinate 30-something new contributions to existing projects? Will the groups all work on distinct features? How would they be graded? It wouldn't really make sense for multiple groups to work on the exact same feature, since only one implementation would be committed. Likewise, for the graduates, do the 80 students work on fixing 80 different bugs? And then refactor 80 different pieces of code? Again, it wouldn't make sense to have them all refactoring the same piece of code.<br />
<br />
[[Category:POSSE 2014-11]]<br />
[[Category:POSSE 2016-06]]<br />
[[Category:POSSE 2016-11]]</div>Cmurphyhttp://www.foss2serve.org/index.php/User:CmurphyUser:Cmurphy2018-06-17T23:40:30Z<p>Cmurphy: /* Chris Murphy */</p>
<hr />
<div>==Chris Murphy==<br />
<br />
I am an Associate Professor of Practice in the Dept. of Computer & Information Science at the University of Pennsylvania: http://www.seas.upenn.edu/~cdmurphy<br />
<br />
My current interests include online education, student contributions to open source software projects, and how these affect diversity and inclusion within CS.<br />
<br />
Prior to joining Penn in 2010, I completed a PhD in Computer Science at Columbia University, where my research focused on software testing. Before that, I worked as a professional software developer in Boston, San Francisco, and London after earning a BS in Computer Engineering from Boston University.<br />
<br />
Somewhere along the way, I also spent two years teaching English in Seoul, but that's not really part of the narrative hahaha...<br />
<br />
You can find out more in my [http://www.seas.upenn.edu/~cdmurphy/ChrisMurphy-CV.pdf | CV] and on my LinkedIn page!<br />
<br />
Chris occasionally teaches a course on open-source software development. A webpage with an overview of the course is available at http://www.seas.upenn.edu/~cdmurphy/foss/ and the full syllabus is [[FOSS Course, UPenn, Murphy|here]]. Other resources not hosted on foss2serve are available at https://github.com/ChrisMurphyOnline/open-source-software-development-course<br />
<br />
==POSSE 11-2014 Stage 1 Activities==<br />
===Part A: Intro to IRC, Part 1===<br />
* How do people interact? briefly, but politely, and usually offering to help out or at least make helpful suggestions<br />
* What is the pattern of communication? generally focused on a particular issue: someone raises it and the others try to help out<br />
* Are there any terms that seem to have special meaning? technical terms, of course, but also the commands to MeetBot<br />
* Can you make any other observations? amber does not seem to be a big fan of capitalization and punctuation :-p<br />
<br />
===Part A: Intro to IRC, Part 3===<br />
* I observed the #openMRS channel on Tues Oct 14.<br />
* There was a "global notice" that went to all freenode users; I didn't realize it at first, as I thought it was just for the channel users, but I see the difference now.<br />
* There was a conversation between two users in which one was attempting to help the other get the code downloaded and installed. <br />
* The OpenMRSBot occassionally sent messages based on activities in Jira<br />
* At 10am EDT, a user started the daily SCRUM meeting. Users were asked to give updates in order, however two of the three were absent<br />
* I noticed that most of the conversations were between two people, in which they included the other person's nickname at the start of their entry<br />
<br />
===Part A: Project Anatomy===<br />
====Sugar Labs====<br />
=====Community=====<br />
* Activity Team: develops and maintains many of the activities; there are 2 coordinators and 13 contributors<br />
* Development Team: build and maintain the core Sugar environment; there is no coordinator and 4 "people" listed; there is no overlap with the Activity team<br />
* Documentation Team: provide the Sugar community with high quality documentation; no coordinator or contributors are listed<br />
=====Tracker=====<br />
* types: defects and enhancements<br />
* info available for each ticket: ID#, reported by, owned by, priority, milestone, component, version, severity, keywords, CC, distribution/OS, status, description, attachments, change history<br />
=====Repository=====<br />
it seems to be a local repository<br />
=====Release Cycle=====<br />
The roadmap is updated at the beginning of each release cycle.<br />
<br />
====Sahana Eden====<br />
=====Community=====<br />
* Developers: people who develop the software; names and roles do not seem to be defined, unlike Sugar Labs; rather, there seems to be more "how to get started" info here<br />
* Testers: non-technical users who do QA through manual testing; there are links for documenting test cases, as well as links for developers<br />
* Designers: people who work on the user interface<br />
====Tracker====<br />
* types: defect/bug, documentation, enhancement, task<br />
* info available for each ticket: ID#, reported by, owned by, priority, milestone, component, version, keywords, CC, due date, launchpad bug, description, attachments, change history<br />
* this is different from Sugar Labs because the tickets are organized into reports, rather than just presenting one large list<br />
====Repository====<br />
since this is hosted on github, it is a shared/web repository<br />
====Release Cycle====<br />
The roadmap/milestones seems to be based on the completion of features and not a specific date-driven release cycle.<br />
<br />
===Part B: Project Evaluation Activity===<br />
[[File:Mifos_Evaluation_Template.xlsx]]<br />
<br />
===Part B: FOSS in Courses Planning 1===<br />
====Step 3.====<br />
For my undergraduate software engineering course, the motivation is to give students experience working with a large code base, and to get them thinking about the design of software. So I am interested in having the students add functionality to the project (along with corresponding test cases) but also to think about how they’re identifying components, the relationship between those components, etc. <br />
<br />
For my graduate software engineering course, the emphasis is on “what is good code?” so we spend a lot of time reviewing code and figuring out ways to improve it. So the HFOSS-related activities would include conducting code inspections and then refactoring code to improve its design and internal quality, as well as bug fixing and regression testing.<br />
<br />
====Step 4.====<br />
For the undergraduate course, the activities would be based on the proposed CS2 assignments from the “50 ways to be a FOSSer” blog. I would have the students look at the existing code and document the design using UML, and also ask them to identify the usage (or attempted usage) of the design patterns we study in class. Then I would have them propose a feature, design the components using appropriate patterns, and then implement and test the feature.<br />
<br />
For the graduate course, I would use some combination of the “Quality & Testing” and “Coding & Style” activities from the same blog. Students would start out by choosing one of the open defects, writing a test case that demonstrates that bug, and then fixing the bug. I would also ask them to create additional test cases for that component using test set adequacy metrics and then fix any other bugs they reveal. Then, once they’re comfortable with the expected functionality, they would conduct a code inspection, document “code smells”, and then refactor the code to improve its quality.<br />
<br />
===Part C: Bug Tracker Activity===<br />
====Part 1. Bug Reports====<br />
1. Define what each of the column names below indicate. Include the range of possible values for 2-7 below. Feel free to explore beyond the page to find more information.<br />
<br />
1. ID: a unique ID for each bug<br />
<br />
2. Sev: the severity of the bug; normal, minor, major, critical, enhancement, blocker, trivial<br />
<br />
3. Pri: priority; low, normal, high, urgent<br />
<br />
4. OS: operating system; all, Linux, open, Windows, Solaris, Mac, other<br />
<br />
5. Product: which product the bug affects; lots of possible values<br />
<br />
6. Status: current status of the bug; unconfirmed, new, assigned, reopened, need info<br />
<br />
7. Resolution: no possible values listed; maybe a link to a description of how it was resolved?<br />
<br />
8. Summary: summary of the bug<br />
<br />
2. Describe how you discovered the definitions and how did you find the information from above (hint: the advanced search shows the options or the Reports link has a link)? I sorted each category to see the possible options, and then opened up a bug report and read the longer description to see what was there<br />
<br />
3. Identify the order in which the bugs are initially displayed? seems like they're sorted by status<br />
<br />
4. What is the meaning of the shading of some bug reports? hmmm… I can't tell; seems like every other entry is shaded, unless it's an enhancement<br />
<br />
5. What is the meaning of the colors used when describing a bug (red, gray, black)? red is for blocker or critical status; gray is for enhancements<br />
<br />
6. Select a bug that you think that you might be able to fix and look at it more closely (click on the bug number). -- I chose 561837<br />
<br />
1. Identify when the bug was submitted. -- 2008-11-21<br />
<br />
2. Identify if there has been recent discussion about the bug? -- not since 2013-08-14<br />
<br />
3. Is the bug current? -- doesn't seem like it<br />
<br />
4. Is the bug assigned? To whom? -- to At-spi maintainer(s)<br />
<br />
5. Describe what you would need to do to fix the bug. -- it looks like someone created a patch but no one confirmed it, so I guess I'd need to know whether the patch is okay<br />
<br />
7. Repeat the previous step with a different kind of bug. -- I chose 437375<br />
<br />
1. submitted 2007-05-10<br />
<br />
2. no recent discussion since 2011-06-23<br />
<br />
3. doesn't seem current<br />
<br />
4. assigned to ATK maintainer(s)<br />
<br />
5. this bug describes an ambiguity in the doc; I'd need to make sure that the description is unambiguous using the terminology expected by the intended audience<br />
<br />
====Part 2. Collective Reports====<br />
<br />
2. How many bug reports were opened in the last week? How many were closed? -- 325 reports opened and 386 reports closed.<br />
<br />
3. What was the general trend last week? Were more bugs opened than closed or vice versa? -- more closed than opened<br />
<br />
4. Who were the top three bug closers? Why is this important to know? -- Jean-François Fortin Tam, Bastien Nocera, Matthias Clasen -- perhaps they are the ones who know the code best<br />
<br />
5. Who were the top three bug reporters? Are these the same as the top three bug closes? What is the overlap in these two lists? -- Jo, Jean-François Fortin Tam, Michael Catanzaro -- not too much overlap except for Jean-Francois<br />
<br />
6. Who are the top three contributors of patches? -- Ray Strode [halfline], Bastien Nocera, Marcos Chavarria Teijeiro<br />
<br />
7. Who are the top three reviewers of patches? What is the overlap between these lists and the bug closers and bug reporters? What is the overlap between patch contributors and patch reviewers? -- Sebastian Dröge (slomo), Florian Müllner, Jonas Danielsson -- there is a little overlap between patch contributors and bug closers, which makes sense because once you patch it, you can mark it closed; not too much overlap between reviewers and contributors, which is to be expected, since the people who contribute a patch should not be reviewing their own work<br />
<br />
10. What other reports can you generate? -- tons!<br />
<br />
<br />
===Part C: FOSS in Courses Planning 2===<br />
====Part 1.====<br />
For both my undergraduate and graduate courses, I imagine that the FOSS activities would consist of two homework assignments: one in which the students evaluate the existing code, and then another in which they add to the code base or somehow improve the code.<br />
<br />
I can imagine having a lecture around the benefits of FOSS for the undergrads, but I wouldn't think it's necessary for the homework assignments, which are simply focused on "existing code".<br />
<br />
As for a project, we typically do customer-focused apps for our local community, and for undergrads the focus is on developing an app from scratch, but if a group of graduate students was particularly interested in contributing to a FOSS project, we could certainly explore that option. <br />
<br />
====Part 2.====<br />
Learning outcomes: For the undergrads, to be able to document the design (e.g. using UML) of existing code, to convert a set of requirements into a design, and to implement and test the code. For the graduate students, to be able to adequately test existing code, to debug code, and to refactor code.<br />
<br />
Pre-requisite knowledge: Aside from the programming language of choice, I don't think there's much in the way of pre-reqs. Part of the challenge, especially for the graduates, would be to figure out the intent of the code as they are working with it.<br />
<br />
Time estimates: It may take quite a while (~20 hours) to identify a project, figure out parts of the code to work with, identify the work that can realistically be done, and then write up the assignment and put together a grading rubric. For the undergrads, if we want to contribute new features to the project, we'd definitely need to coordinate that with the community, particularly as we have 130+ students in that class.<br />
<br />
Input required for community: If we want to add new features, we will likely need to have those approved/vetted. For things like bug fixing and refactoring, though, I suspect the primary input will be coding conventions.<br />
<br />
Assessment: For the undergrads, the documentation of the design of the code can be an individual assignment. If they are to design and implement new features, though, that would probably be in groups, primarily to address issues of scale. I wouldn't want to associate getting the work committed with the grade, though, as that is somewhat out of our control. For the graduates, the assignments (fixing bugs, writing tests, refactoring) could be done in pairs, and I might be more inclined to require that bug fixes or refactoring be committed, since presumably someone in the community would be able to assess their work as "good enough".<br />
<br />
Questions/concerns: The more I think about this, the more concerned I get about issues of scale. My undergrad class has over 130 students; the graduate class has around 80. Documenting the design of the existing code is something that scales, since I wouldn't expect that we'd actually contribute that back to the project. But for the undergrads, even if they work in groups of four, what sort of effort will it take on my part to coordinate 30-something new contributions to existing projects? Will the groups all work on distinct features? How would they be graded? It wouldn't really make sense for multiple groups to work on the exact same feature, since only one implementation would be committed. Likewise, for the graduates, do the 80 students work on fixing 80 different bugs? And then refactor 80 different pieces of code? Again, it wouldn't make sense to have them all refactoring the same piece of code.<br />
<br />
[[Category:POSSE 2014-11]]<br />
[[Category:POSSE 2016-06]]<br />
[[Category:POSSE 2016-11]]</div>Cmurphyhttp://www.foss2serve.org/index.php/POSSE_2018-06_ParticipantsPOSSE 2018-06 Participants2018-06-17T23:33:39Z<p>Cmurphy: </p>
<hr />
<div>The participants in [[POSSE 2018-06]] are:<br />
* [[User:Darci.burdge|Darci Burdge]], Nassau Community College - email: Darci.Burdge@ncc.edu<br />
* [[User:Ahernandez|Alberto Castro-Hernández]], Miami University - email: castroa@miamioh.edu<br />
* [[User:Heidi.ellis|Heidi Ellis]], Western New England University - email: ellis at wne.edu, Blog: [https://heidiellis.wordpress.com/ Heidi Ellis' blog]<br />
* [[User:Jfoster | James Foster]], Walla Walla University - email: James.Foster@WallaWalla.edu<br />
* [[User:Mfranklin|D. Michael Franklin]], Kennesaw State University, Marietta Campus - email: mfranklin@kennesaw.edu<br />
* [[User:hislop | Greg Hislop]], Drexel University - email: hislop at drexel.edu, Blog: [https://hislop.wordpress.com/ Notes from Greg Hislop]<br />
* [[User:stoney.jackson|Stoney Jackson]], Western New England University - email: dr.stoney@gmail.com<br />
* [[User:Wjin | Wei Jin]], Georgia Gwinnett College - email: wjin at ggc.edu<br />
* [[User:Clif.kussmaul|Clif Kussmaul]], Muhlenberg College - email: clif@kussmaul.org<br />
* [[User:Lori.postner|Lori Postner]], Nassau Community College - email: Lori.Postner@ncc.edu<br />
* [[User:aroca|Alberto Roca]], DiverseScholar - email: info(at)DiverseScholar(DOT)org, Essays: [http://www.minoritypostdoc.org/view/profile-RocaAI.html#features DiverseScholar original articles]<br />
* [[User:hshahria|Hossain Shahriar]], Kennesaw State University - email: hshahria@kennesaw.edu, Essays: [http://www.foss2serve.org/index.php/User:Hshahria#features introduction]<br />
* [[User:Mmagnusson|Matt Magnusson]], University of New Hampshire - email: mfm2@unh.edu<br />
* [[User:Bkim|Bo Kim]], Southern New Hampshire University - email: b.kim@snhu.edu<br />
* [[User:Ldeng|Lin Deng]], Towson University - email: ldeng@towson.edu<br />
* [[User:Fsiddiqui|Farhan Siddiqui]], Dickinson College - email: siddiquf@dickinson.edu<br />
* [[User:Dferebee|Denise Ferebee]], LeMoyne-Owen College - email: denise_ferebee@loc.edu<br />
* [[User:Mgerosa|Marco Gerosa]], Northern Arizona University - email: Marco.Gerosa@nau.edu<br />
* [[User:Cmurphy|Chris Murphy]], University of Pennsylvania - email: cdmurphy@seas.upenn.edu</div>Cmurphyhttp://www.foss2serve.org/index.php/IRC_Meeting_3IRC Meeting 32018-04-27T19:03:08Z<p>Cmurphy: /* Agenda */</p>
<hr />
<div>{{Category:IRC}}<br />
<br />
== Agenda ==<br />
<br />
'''IRC Meeting 3''' has the following goals:<br />
<br />
* Discuss progress - please continue to log feedback in the [https://docs.google.com/spreadsheets/d/1hG45B8aK4A7JaSDx4PE3UvXQNMw6Ph-iE53YqvMOrWQ/edit?ts=5ae33a5d#gid=0 activity evaluation spreadsheet]<br />
* Discuss the results of B.4 and C.3 (FOSS in Courses Planning I and II) and answer any questions<br />
** These will be used as a base for [[Stage 2 Activities]] so more detail is better<br />
* Sign up for Stage 2 groups [http://foss2serve.org/index.php/Stage2_Groups here]<br />
** Join one project and one or more courses<br />
* Enter your arrival and departure times in the [https://docs.google.com/spreadsheets/d/1CRYf4xY6O0Pq5bacvMcyvxBDQtFR4iVpE6V56OcNxgU/edit#gid=0 POSSE Travel Arrangement Google Sheet] <br />
* Please make sure to arrive at Stage 2 with Git installed on your laptop and having completed C.2.<br />
* As always, please remember to log your progress in the [https://docs.google.com/spreadsheets/d/1hG45B8aK4A7JaSDx4PE3UvXQNMw6Ph-iE53YqvMOrWQ/edit?ts=5ae33a5d#gid=0 spreadsheet]<br />
<br />
== To Join ==<br />
<br />
Server: <br />
/attach irc.freenode.net<br />
Channel: <br />
/join #foss2serve<br />
<br />
As with previous IRC meetings, we'll have several of the POSSE team members to facilitate. We've asked people to sign up for different times to accommodate schedules, but also so that everyone will get to talk some without the conversation getting too confusing. <br />
<br />
== Notes ==<br />
<br />
* The IRC meetings will be recorded and processed by a MeetBot.<br />
* The meeting logs and summaries will be at http://meetbot-raw.fedoraproject.org/foss2serve/ under the date of the meeting.<br />
* They will also be on the wiki page for the individual POSSE.<br />
<br />
<br />
[[Category:Instructor Activities]]<br />
[[Category:Communication and Tools]]<br />
[[Category:IRC]]</div>Cmurphyhttp://www.foss2serve.org/index.php/FOSS_in_Courses_2_(Instructors)FOSS in Courses 2 (Instructors)2018-04-27T18:57:19Z<p>Cmurphy: /* Background */</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
FOSS in Courses 2<br />
|overview= <br />
Learner will identify 1-3 HFOSS topics and/or learning ideas for a course.<br />
|prerequisites=<br />
Completion of [[FOSS in Courses 1 (Instructors)]]<br />
|objectives=<br />
# Identify 1-3 HFOSS topics and/or learning ideas for a course.<br />
|process skills=<br />
}}<br />
<br />
=== Background ===<br />
<br />
This activity is an extension of [[FOSS in Courses 1 (Instructors)]]. <br />
The goal of this activity is to have 1-3 topics and/or learning ideas to bring for discussion to the workshop and receive feedback on. <br />
We do not expect that these activities/ideas will be completely fleshed out, but rather provide an initial starting point to think about.<br />
<br />
=== Directions ===<br />
<br />
# Recalling your list of activities/topics from [[FOSS in Courses 1 (Instructors)]], identify the ways that these FOSS activities/topics can be structured. Possibilities include:<br />
#* Lectures<br />
#* In-class activity<br />
#* Homework<br />
#* Stream of related activities<br />
#* Project<br />
# List the revised activities on your wiki page. For each activity/topic:<br />
## Identify some possible learning outcomes that should be fulfilled with the activities/task.<br />
## Describe any prerequisite knowledge needed to complete the activity. This does not need to be a complete list. <br />
## Estimate the time required for instructor prep, for student completion and elapsed calendar time. Are you going to have to synchronize your activity with the community or can the activity/topic be covered independent of the HFOSS community schedule. <br />
## Think about possible input required from the HFOSS community. How much input is required and what kind?<br />
## If the result of the activity is contributed back to the HFOSS project, describe the contribution and its usefulness.<br />
## Describe the assessment/grading approach - What will the basis for grading be? Will this be a team activity or individual? Is there a role for the HFOSS community in helping assess student work? For instance, must the work be committed or otherwise accepted by the community? <br />
## List any questions or concerns that you have about the activity/task. <br />
## List any stumbling blocks or barriers to carrying out the activity/task.<br />
<br />
=== Deliverables ===<br />
<br />
POSSE: An entry on your foss2serve user wiki page that includes a list of 1-3 HFOSS topics and/or learning ideas for a course.<br />
<br />
= Notes for Instructors =<br />
<br />
The remaining sections of this document are intended for the instructor. They are not part of the learning activity that would be given to students.<br />
<br />
=== Assessment ===<br />
<br />
* How will the activity be graded?<br />
* How will learning will be measured?<br />
* Include sample assessment questions/rubrics.<br />
<br />
{| class="wikitable"<br />
! Criteria<br />
! Level 1 (fail)<br />
! Level 2 (pass)<br />
! Level 3 (good)<br />
! Level 4 (exceptional)<br />
|-<br />
| '''Criteria 1'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Criteria 2'''<br />
| <br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* What should the instructor know before using this activity?<br />
* What are some likely difficulties that an instructor may encounter using this activity?<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
|acm topic=<br />
|difficulty=<br />
|time=<br />
60-90 minutes<br />
|environment=<br />
Access to Internet/Web and web browser. <br />
|author=<br />
|source=<br />
None.<br />
|license=<br />
{{License CC BY SA}}<br />
}}<br />
<br />
=== Suggestions for Open Source Community ===<br />
<br />
Suggestions for an open source community member who is working in conjunction with the instructor.<br />
<br />
[[Category:Instructor Activities]]</div>Cmurphyhttp://www.foss2serve.org/index.php/FOSS_in_Courses_2_(Instructors)FOSS in Courses 2 (Instructors)2018-04-27T18:56:59Z<p>Cmurphy: /* Background */</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
FOSS in Courses 2<br />
|overview= <br />
Learner will identify 1-3 HFOSS topics and/or learning ideas for a course.<br />
|prerequisites=<br />
Completion of [[FOSS in Courses 1 (Instructors)]]<br />
|objectives=<br />
# Identify 1-3 HFOSS topics and/or learning ideas for a course.<br />
|process skills=<br />
}}<br />
<br />
=== Background ===<br />
<br />
This activity is an extension of [[FOSS in Courses 1 (Instructors)]]. <br />
The goal of this activity is to have 1-3 topics and/or learning ideas to bring for discussion to the workshop and receive feedback on. <br />
We do not expect that these activities/ideas will be completely fleshed out, but to provide an initial starting point to think about.<br />
<br />
=== Directions ===<br />
<br />
# Recalling your list of activities/topics from [[FOSS in Courses 1 (Instructors)]], identify the ways that these FOSS activities/topics can be structured. Possibilities include:<br />
#* Lectures<br />
#* In-class activity<br />
#* Homework<br />
#* Stream of related activities<br />
#* Project<br />
# List the revised activities on your wiki page. For each activity/topic:<br />
## Identify some possible learning outcomes that should be fulfilled with the activities/task.<br />
## Describe any prerequisite knowledge needed to complete the activity. This does not need to be a complete list. <br />
## Estimate the time required for instructor prep, for student completion and elapsed calendar time. Are you going to have to synchronize your activity with the community or can the activity/topic be covered independent of the HFOSS community schedule. <br />
## Think about possible input required from the HFOSS community. How much input is required and what kind?<br />
## If the result of the activity is contributed back to the HFOSS project, describe the contribution and its usefulness.<br />
## Describe the assessment/grading approach - What will the basis for grading be? Will this be a team activity or individual? Is there a role for the HFOSS community in helping assess student work? For instance, must the work be committed or otherwise accepted by the community? <br />
## List any questions or concerns that you have about the activity/task. <br />
## List any stumbling blocks or barriers to carrying out the activity/task.<br />
<br />
=== Deliverables ===<br />
<br />
POSSE: An entry on your foss2serve user wiki page that includes a list of 1-3 HFOSS topics and/or learning ideas for a course.<br />
<br />
= Notes for Instructors =<br />
<br />
The remaining sections of this document are intended for the instructor. They are not part of the learning activity that would be given to students.<br />
<br />
=== Assessment ===<br />
<br />
* How will the activity be graded?<br />
* How will learning will be measured?<br />
* Include sample assessment questions/rubrics.<br />
<br />
{| class="wikitable"<br />
! Criteria<br />
! Level 1 (fail)<br />
! Level 2 (pass)<br />
! Level 3 (good)<br />
! Level 4 (exceptional)<br />
|-<br />
| '''Criteria 1'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Criteria 2'''<br />
| <br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* What should the instructor know before using this activity?<br />
* What are some likely difficulties that an instructor may encounter using this activity?<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
|acm topic=<br />
|difficulty=<br />
|time=<br />
60-90 minutes<br />
|environment=<br />
Access to Internet/Web and web browser. <br />
|author=<br />
|source=<br />
None.<br />
|license=<br />
{{License CC BY SA}}<br />
}}<br />
<br />
=== Suggestions for Open Source Community ===<br />
<br />
Suggestions for an open source community member who is working in conjunction with the instructor.<br />
<br />
[[Category:Instructor Activities]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Intro_to_Bug_Trackers_(Activity)Intro to Bug Trackers (Activity)2018-04-27T18:53:18Z<p>Cmurphy: /* Part 2 - Collective Reports */</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
Intro to Bug Trackers<br />
|overview= <br />
Learners will gain an understanding of the features of bug trackers and how they are used to identify work items to be completed in a FOSS project. <br />
|prerequisites=<br />
None.<br />
|objectives=<br />
# Describe the role that a bug tracker plays in a FOSS project.<br />
# Describe the different types of issues stored in a bug tracker and their priorities.<br />
# Identify and track the status of a particular bug in a project. <br />
|process skills=<br />
}}<br />
<br />
<br />
=== Background ===<br />
<br />
Bug tracking systems are a tool for change management and organization used by FOSS projects. <br />
Bug trackers do far more than simply keep track of bugs. <br />
They also are used to hold new feature requests, patches, and some tasks. <br />
Bug trackers are also called request trackers, issue trackers, and ticket systems. <br />
Please read the two readings below for a more complete treatment of bug trackers and their use in FOSS projects.<br />
<br />
* [http://producingoss.com/en/bug-tracker.html Karl Fogel's chapter on bug trackers]<br />
* [http://en.wikipedia.org/wiki/Bug_tracking_system Bug Tracking System (Wikipedia)]<br />
<br />
=== Directions ===<br />
<br />
We will begin by looking at a typical Bugzilla instance for a project. <br />
We will be using GNOME's Bugzilla instance, but specifically looking at the bugs for the Accessibility Team. <br />
<br />
== Part 1 - Bug Reports ==<br />
# Open a browser and go to the [https://bugzilla.gnome.org/buglist.cgi?type0-7-0=notequals;field0-3-0=product;keywords=accessibility;type0-1-0=notequals;type0-5-0=notequals;keywords_type=allwords;value0-5-0=accerciser;value0-4-0=at-poke;field0-1-0=product;field0-0-0=product;type0-4-0=notequals;field0-6-0=product;value0-3-0=gnome-mag;field0-7-0=product;query_format=advanced;value0-2-0=Dasher;value0-6-0=gnome-speech;value0-1-0=Gok;type0-3-0=notequals;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;field0-2-0=product;field0-5-0=product;field0-4-0=product;type0-6-0=notequals;type0-0-0=notequals;value0-0-0=Orca;type0-2-0=notequals GNOME Accessibility Bugs]<br />
# Define what each of the column names below indicate. Include the range of possible values for 2-7 below. Feel free to explore beyond the page to find more information.<br />
## ID <br />
## Sev <br />
## Pri<br />
## OS <br />
## Product <br />
## Status <br />
## Resolution <br />
## Summary <br />
# Describe how you discovered the definitions and how you found the information from above (hint: the advanced search shows the options or the Reports link has a link).<br />
# Identify the order in which the bugs are initially displayed.<br />
# What is the meaning of the colors used when describing a bug (red, gray, black)? (Hint: click on the Bug ID and examine the fields)<br />
# Select a bug that you think that you might be able to fix and look at it more closely (click on the bug number). <br />
## When was the bug submitted?<br />
## What recent discussion has there been about the bug?<br />
## Is the bug current?<br />
## Is the bug assigned? To whom?<br />
## Describe what you would need to do to fix the bug. <br />
# Repeat the previous step with a different kind of bug.<br />
<br />
== Part 2 - Collective Reports ==<br />
<br />
# Click on the “Reports” link on the top of the page.<br />
# Click on the "Summary of Bug Activity for the last week".<br />
# How many bug reports were opened in the last week? How many were closed? <br />
# What was the general trend last week? Were more bugs opened than closed or vice versa? <br />
# Who were the top three bug closers? Why is this important to know? <br />
# Who were the top three bug reporters? Are these the same as the top three bug closes? What is the overlap in these two lists? <br />
# Who are the top three reviewers of patches? What is the overlap between these lists and the bug closers and bug reporters? What is the overlap between patch contributors and patch reviewers? <br />
# Click on the "Reports" link at the top of the page and then click on the “Generate Graphical Reports” link.<br />
# Plot a line graph of the severity of bugs by component for Orca:<br />
## Select "Severity" for the vertical axis<br />
## Select "Component" for the horizontal axis<br />
## Select "Bar Graph" for type of graph<br />
## Leave the "Multiple Images" as <none><br />
## Scroll down and select Orca from the Product menu. <br />
## Click "Generate Report". <br />
# What class were the majority of the bugs for braille? <br />
# What other reports can you generate?<br />
<br />
<br />
===Deliverables ===<br />
<br />
POSSE: On your user wiki page, a section describing the results of your exploration below.<br />
<br />
= Notes for Instructors =<br />
<br />
The remaining sections of this document are intended for the instructor. They are not part of the learning activity that would be given to students.<br />
<br />
===Assessment: ===<br />
<br />
* How will the activity be graded?<br />
* How will learning will be measured?<br />
* Include sample assessment questions/rubrics.<br />
<br />
{| border="1" class="wikitable"<br />
! Criteria<br />
! Level 1 (fail)<br />
! Level 2 (pass)<br />
! Level 3 (good)<br />
! Level 4 (exceptional)<br />
|-<br />
| '''The purpose of the project'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Why the project is open source'''<br />
| <br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* What should the instructor know before using this activity?<br />
* What are some likely difficulties that an instructor may encounter using this activity?<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
|acm topic=<br />
|difficulty=<br />
Easy<br />
|time=<br />
60 minutes<br />
|environment=<br />
Access to Internet/Web and web browser. <br />
|author=<br />
Heidi Ellis<br />
|source=<br />
|license=<br />
{{License CC BY SA}}<br />
}}<br />
<br />
=== Suggestions for Open Source Community: ===<br />
<br />
Suggestions for an open source community member who is working in conjunction with the instructor.<br />
<br />
<br />
[[Category:Learning Activity]]<br />
[[Category:Communication and Tools]]<br />
[[Category:Bugzilla]]<br />
[[Category:CS Principles]]<br />
[[Category:CS2]]<br />
[[Category: Good Draft]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Intro_to_Bug_Trackers_(Activity)Intro to Bug Trackers (Activity)2018-04-27T18:51:33Z<p>Cmurphy: /* Part 1 - Bug Reports */</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
Intro to Bug Trackers<br />
|overview= <br />
Learners will gain an understanding of the features of bug trackers and how they are used to identify work items to be completed in a FOSS project. <br />
|prerequisites=<br />
None.<br />
|objectives=<br />
# Describe the role that a bug tracker plays in a FOSS project.<br />
# Describe the different types of issues stored in a bug tracker and their priorities.<br />
# Identify and track the status of a particular bug in a project. <br />
|process skills=<br />
}}<br />
<br />
<br />
=== Background ===<br />
<br />
Bug tracking systems are a tool for change management and organization used by FOSS projects. <br />
Bug trackers do far more than simply keep track of bugs. <br />
They also are used to hold new feature requests, patches, and some tasks. <br />
Bug trackers are also called request trackers, issue trackers, and ticket systems. <br />
Please read the two readings below for a more complete treatment of bug trackers and their use in FOSS projects.<br />
<br />
* [http://producingoss.com/en/bug-tracker.html Karl Fogel's chapter on bug trackers]<br />
* [http://en.wikipedia.org/wiki/Bug_tracking_system Bug Tracking System (Wikipedia)]<br />
<br />
=== Directions ===<br />
<br />
We will begin by looking at a typical Bugzilla instance for a project. <br />
We will be using GNOME's Bugzilla instance, but specifically looking at the bugs for the Accessibility Team. <br />
<br />
== Part 1 - Bug Reports ==<br />
# Open a browser and go to the [https://bugzilla.gnome.org/buglist.cgi?type0-7-0=notequals;field0-3-0=product;keywords=accessibility;type0-1-0=notequals;type0-5-0=notequals;keywords_type=allwords;value0-5-0=accerciser;value0-4-0=at-poke;field0-1-0=product;field0-0-0=product;type0-4-0=notequals;field0-6-0=product;value0-3-0=gnome-mag;field0-7-0=product;query_format=advanced;value0-2-0=Dasher;value0-6-0=gnome-speech;value0-1-0=Gok;type0-3-0=notequals;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;field0-2-0=product;field0-5-0=product;field0-4-0=product;type0-6-0=notequals;type0-0-0=notequals;value0-0-0=Orca;type0-2-0=notequals GNOME Accessibility Bugs]<br />
# Define what each of the column names below indicate. Include the range of possible values for 2-7 below. Feel free to explore beyond the page to find more information.<br />
## ID <br />
## Sev <br />
## Pri<br />
## OS <br />
## Product <br />
## Status <br />
## Resolution <br />
## Summary <br />
# Describe how you discovered the definitions and how you found the information from above (hint: the advanced search shows the options or the Reports link has a link).<br />
# Identify the order in which the bugs are initially displayed.<br />
# What is the meaning of the colors used when describing a bug (red, gray, black)? (Hint: click on the Bug ID and examine the fields)<br />
# Select a bug that you think that you might be able to fix and look at it more closely (click on the bug number). <br />
## When was the bug submitted?<br />
## What recent discussion has there been about the bug?<br />
## Is the bug current?<br />
## Is the bug assigned? To whom?<br />
## Describe what you would need to do to fix the bug. <br />
# Repeat the previous step with a different kind of bug.<br />
<br />
== Part 2 - Collective Reports ==<br />
<br />
# Click on the “Reports” link on the top of the page.<br />
# Click on the "Summary of Bug Activity for the last week".<br />
# How many bug reports were opened in the last week? How many were closed? <br />
# What was the general trend last week? Were more bugs opened than closed or vice versa? <br />
# Who were the top three bug closers? Why is this important to know? <br />
# Who were the top three bug reporters? Are these the same as the top three bug closes? What is the overlap in these two lists? <br />
# Who are the top three reviewers of patches? What is the overlap between these lists and the bug closers and bug reporters? What is the overlap between patch contributors and patch reviewers? <br />
# Click on the “Generate Graphical Reports” link.<br />
# Plot a line graph of the severity of bugs by component for Orca:<br />
## Select "Severity" for the vertical axis<br />
## Select "Component" for the horizontal axis<br />
## Select "Bar Graph" for type of graph<br />
## Leave the "Multiple Images" as <none><br />
## Scroll down and select Orca from the Product menu. <br />
## Click "Generate Report". <br />
# What class were the majority of the bugs for braille? <br />
# What other reports can you generate?<br />
<br />
<br />
===Deliverables ===<br />
<br />
POSSE: On your user wiki page, a section describing the results of your exploration below.<br />
<br />
= Notes for Instructors =<br />
<br />
The remaining sections of this document are intended for the instructor. They are not part of the learning activity that would be given to students.<br />
<br />
===Assessment: ===<br />
<br />
* How will the activity be graded?<br />
* How will learning will be measured?<br />
* Include sample assessment questions/rubrics.<br />
<br />
{| border="1" class="wikitable"<br />
! Criteria<br />
! Level 1 (fail)<br />
! Level 2 (pass)<br />
! Level 3 (good)<br />
! Level 4 (exceptional)<br />
|-<br />
| '''The purpose of the project'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Why the project is open source'''<br />
| <br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* What should the instructor know before using this activity?<br />
* What are some likely difficulties that an instructor may encounter using this activity?<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
|acm topic=<br />
|difficulty=<br />
Easy<br />
|time=<br />
60 minutes<br />
|environment=<br />
Access to Internet/Web and web browser. <br />
|author=<br />
Heidi Ellis<br />
|source=<br />
|license=<br />
{{License CC BY SA}}<br />
}}<br />
<br />
=== Suggestions for Open Source Community: ===<br />
<br />
Suggestions for an open source community member who is working in conjunction with the instructor.<br />
<br />
<br />
[[Category:Learning Activity]]<br />
[[Category:Communication and Tools]]<br />
[[Category:Bugzilla]]<br />
[[Category:CS Principles]]<br />
[[Category:CS2]]<br />
[[Category: Good Draft]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Intro_to_Bug_Trackers_(Activity)Intro to Bug Trackers (Activity)2018-04-27T18:50:29Z<p>Cmurphy: /* Part 1 - Bug Reports */</p>
<hr />
<div>__NOTOC__<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
Intro to Bug Trackers<br />
|overview= <br />
Learners will gain an understanding of the features of bug trackers and how they are used to identify work items to be completed in a FOSS project. <br />
|prerequisites=<br />
None.<br />
|objectives=<br />
# Describe the role that a bug tracker plays in a FOSS project.<br />
# Describe the different types of issues stored in a bug tracker and their priorities.<br />
# Identify and track the status of a particular bug in a project. <br />
|process skills=<br />
}}<br />
<br />
<br />
=== Background ===<br />
<br />
Bug tracking systems are a tool for change management and organization used by FOSS projects. <br />
Bug trackers do far more than simply keep track of bugs. <br />
They also are used to hold new feature requests, patches, and some tasks. <br />
Bug trackers are also called request trackers, issue trackers, and ticket systems. <br />
Please read the two readings below for a more complete treatment of bug trackers and their use in FOSS projects.<br />
<br />
* [http://producingoss.com/en/bug-tracker.html Karl Fogel's chapter on bug trackers]<br />
* [http://en.wikipedia.org/wiki/Bug_tracking_system Bug Tracking System (Wikipedia)]<br />
<br />
=== Directions ===<br />
<br />
We will begin by looking at a typical Bugzilla instance for a project. <br />
We will be using GNOME's Bugzilla instance, but specifically looking at the bugs for the Accessibility Team. <br />
<br />
== Part 1 - Bug Reports ==<br />
# Open a browser and go to the [https://bugzilla.gnome.org/buglist.cgi?type0-7-0=notequals;field0-3-0=product;keywords=accessibility;type0-1-0=notequals;type0-5-0=notequals;keywords_type=allwords;value0-5-0=accerciser;value0-4-0=at-poke;field0-1-0=product;field0-0-0=product;type0-4-0=notequals;field0-6-0=product;value0-3-0=gnome-mag;field0-7-0=product;query_format=advanced;value0-2-0=Dasher;value0-6-0=gnome-speech;value0-1-0=Gok;type0-3-0=notequals;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;field0-2-0=product;field0-5-0=product;field0-4-0=product;type0-6-0=notequals;type0-0-0=notequals;value0-0-0=Orca;type0-2-0=notequals GNOME Accessibility Bugs]<br />
# Define what each of the column names below indicate. Include the range of possible values for 2-7 below. Feel free to explore beyond the page to find more information.<br />
## ID <br />
## Sev <br />
## Pri<br />
## OS <br />
## Product <br />
## Status <br />
## Resolution <br />
## Summary <br />
# Describe how you discovered the definitions and how you found the information from above (hint: the advanced search shows the options or the Reports link has a link).<br />
# Identify the order in which the bugs are initially displayed.<br />
# What is the meaning of the colors used when describing a bug (red, gray, black)? (Hint: click on the Bug ID and examine the fields)<br />
# Select a bug that you think that you might be able to fix and look at it more closely (click on the bug number). <br />
## Identify when the bug was submitted.<br />
## Identify if there has been recent discussion about the bug?<br />
## Is the bug current?<br />
## Is the bug assigned? To whom?<br />
## Describe what you would need to do to fix the bug. <br />
# Repeat the previous step with a different kind of bug.<br />
<br />
== Part 2 - Collective Reports ==<br />
<br />
# Click on the “Reports” link on the top of the page.<br />
# Click on the "Summary of Bug Activity for the last week".<br />
# How many bug reports were opened in the last week? How many were closed? <br />
# What was the general trend last week? Were more bugs opened than closed or vice versa? <br />
# Who were the top three bug closers? Why is this important to know? <br />
# Who were the top three bug reporters? Are these the same as the top three bug closes? What is the overlap in these two lists? <br />
# Who are the top three reviewers of patches? What is the overlap between these lists and the bug closers and bug reporters? What is the overlap between patch contributors and patch reviewers? <br />
# Click on the “Generate Graphical Reports” link.<br />
# Plot a line graph of the severity of bugs by component for Orca:<br />
## Select "Severity" for the vertical axis<br />
## Select "Component" for the horizontal axis<br />
## Select "Bar Graph" for type of graph<br />
## Leave the "Multiple Images" as <none><br />
## Scroll down and select Orca from the Product menu. <br />
## Click "Generate Report". <br />
# What class were the majority of the bugs for braille? <br />
# What other reports can you generate?<br />
<br />
<br />
===Deliverables ===<br />
<br />
POSSE: On your user wiki page, a section describing the results of your exploration below.<br />
<br />
= Notes for Instructors =<br />
<br />
The remaining sections of this document are intended for the instructor. They are not part of the learning activity that would be given to students.<br />
<br />
===Assessment: ===<br />
<br />
* How will the activity be graded?<br />
* How will learning will be measured?<br />
* Include sample assessment questions/rubrics.<br />
<br />
{| border="1" class="wikitable"<br />
! Criteria<br />
! Level 1 (fail)<br />
! Level 2 (pass)<br />
! Level 3 (good)<br />
! Level 4 (exceptional)<br />
|-<br />
| '''The purpose of the project'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Why the project is open source'''<br />
| <br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* What should the instructor know before using this activity?<br />
* What are some likely difficulties that an instructor may encounter using this activity?<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
|acm topic=<br />
|difficulty=<br />
Easy<br />
|time=<br />
60 minutes<br />
|environment=<br />
Access to Internet/Web and web browser. <br />
|author=<br />
Heidi Ellis<br />
|source=<br />
|license=<br />
{{License CC BY SA}}<br />
}}<br />
<br />
=== Suggestions for Open Source Community: ===<br />
<br />
Suggestions for an open source community member who is working in conjunction with the instructor.<br />
<br />
<br />
[[Category:Learning Activity]]<br />
[[Category:Communication and Tools]]<br />
[[Category:Bugzilla]]<br />
[[Category:CS Principles]]<br />
[[Category:CS2]]<br />
[[Category: Good Draft]]</div>Cmurphyhttp://www.foss2serve.org/index.php/PublicationsPublications2017-09-25T02:33:21Z<p>Cmurphy: /* Related Efforts */</p>
<hr />
<div><br />
This page contains references to publications and events that are related to the effort to help students contribute to HFOSS.<br />
<br />
== Papers ==<br />
Journals<br />
* Hislop, Gregory W. and Jackson, Stoney and Ellis, Heidi J.C. (2015). FOSS Artifacts for Evaluating Students on Team Projects. Proceedings of the 16th Annual Conference on Information Technology Education. New York, NY, USA.<br />
<br />
* Hislop, Gregory W. and Ellis, Heidi J.C. (2015). Practical Experiences for IT Students in Humanitarian Free and Open Source Software Projects. Proceedings of the 16th Annual Conference on Information Technology Education. New York, NY, USA.<br />
<br />
* Heidi J. C. Ellis, Gregory W. Hislop, Stoney Jackson, and Lori Postner. 2015. Team Project Experiences in Humanitarian Free and Open Source Software (HFOSS). Trans. Comput. Educ. 15, 4, Article 18 (December 2015), 23 pages. DOI=http://dx.doi.org/10.1145/2684812 <br />
<br />
* Gregory W. Hislop, Heidi J.C. Ellis, S. Monisha Pulimood, Becka Morgan, Suzanne Mello-Stark, Ben Coleman, and Cam Macdonell. 2015. A Multi-Institutional Study of Learning via Student Involvement in Humanitarian Free and Open Source Software Projects. In Proceedings of the eleventh annual International Conference on International Computing Education Research (ICER '15). ACM, New York, NY, USA, 199-206. DOI=http://dx.doi.org/10.1145<br />
<br />
* Ellis, H. J. C., & Hislop, G. W., & Pulimood, S. M., & Morgan, B., & Coleman, B. (2015, June), Software Engineering Learning in HFOSS: A Multi-Institutional Study Paper presented at 2015 ASEE Annual Conference and Exposition, Seattle, Washington. DOI=http://dx.doi.org/10.18260/p.24716<br />
<br />
* Jackson, S., Ellis, H. (2015). Supporting HFOSS using Scrum in a Capstone Course. Abstract and presentation for SIGCAS Symposium on Computing for Social Good. SIGCAS Comput. Soc. 45, 2 (July 2015). <br />
<br />
* Postner, L., Jackson, S., Ellis, H., Hislop, G., Burdge, D., and Goggins, S. (2015). Using Humanitarian Free and Open Source Software (HFOSS) to Introduce Computing for the Social Good. Abstract and presentation for SIGCAS Symposium on Computing for Social Good. SIGCAS Comput. Soc. 45, 2 (July 2015), 3535.<br />
<br />
* Heidi J.C. Ellis, Stoney Jackson, Darci Burdge, Lori Postner, Gregory W. Hislop, and Joanie Diggs. 2014. Learning within a professional environment: shared ownership of an HFOSS project. In Proceedings of the 15th Annual Conference on Information technology education (SIGITE '14). ACM, New York, NY, USA, 95-100. DOI=http://dx.doi.org/10.1145/2656450.2656468 <br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Purcell, M.; Chua, M.; Dziallas, S., "Towards a model of faculty development for FOSS in education," in Software Engineering Education and Training (CSEE&T), 2013 IEEE 26th Conference on , vol., no., pp.269-273, 19-21 May 2013. DOI=http://dx.doi.org/10.1109/CSEET.2013.6595259<br />
<br />
* Ellis, H. J., & Hislop, G. W., & Rodriguez, J. S., & Morelli, R. (2012, June), Student Software Engineering Learning via Participation in Humanitarian FOSS Projects Paper presented at 2012 ASEE Annual Conference, San Antonio, Texas. https://peer.asee.org/21949<br />
<br />
* Heidi J.C. Ellis, Michelle Purcell, and Gregory W. Hislop. 2012. An approach for evaluating FOSS projects for student participation. In Proceedings of the 43rd ACM technical symposium on Computer Science Education (SIGCSE '12). ACM, New York, NY, USA, 415-420. DOI=http://dx.doi.org/10.1145/2157136.2157260<br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Chua, M.; Dziallas, S., "How to involve students in FOSS projects," in Frontiers in Education Conference (FIE), 2011 , vol., no., pp.T1H-1-T1H-6, 12-15 Oct. 2011. DOI=http://dx.doi.org/10.1109/FIE.2011.6142994<br />
<br />
* Ralph Morelli, Allen Tucker, Norman Danner, Trishan R. De Lanerolle, Heidi J. C. Ellis, Ozgur Izmirli, Danny Krizanc, and Gary Parker. 2009. Revitalizing computing education through free and open source software for humanity. Commun. ACM 52, 8 (August 2009), 67-75. DOI=http://doi.acm.org/10.1145/1536616.1536635 <br />
<br />
* Gregory W. Hislop, Heidi J.C. Ellis, and Ralph A. Morelli. 2009. Evaluating student experiences in developing software for humanity. SIGCSE Bull. 41, 3 (July 2009), 263-267. DOI=http://dx.doi.org/10.1145/1595496.1562959 <br />
<br />
* Ellis, H.J.C.; Morelli, R.A.; Hislop, G.W., "Work in progress - challenges to educating students within the Community of Open Source Software for Humanity," in Frontiers in Education Conference, 2008. FIE 2008. 38th Annual , vol., no., pp.S3H-7-S3H-8, 22-25 Oct. 2008. DOI=http://dx.doi.org/10.1109/FIE.2008.4720515<br />
<br />
* Ellis, H.; Morelli, R.A.; Hislop, G.W., "Support for Educating Software Engineers Through Humanitarian Open Source Projects," in Software Engineering Education and Training Workshop, 2008. CSEETW '08. 21st IEEE-CS Conference on , vol., no., pp.1-4, 14-17 April 2008. DOI=http://dx.doi.org/10.1109/CSEETW.2008.5<br />
<br />
* Ellis, H.J.C.; Hislop, G.W., "Fostering the Community of Software Engineering Educators," in Software Engineering Education and Training, 2008. CSEET '08. IEEE 21st Conference on , vol., no., pp.233-237, 14-17 April 2008. DOI=http://dx.doi.org/10.1109/CSEET.2008.18<br />
<br />
* Ellis, H.J.C.; Morelli, R.A.; de Lanerolle, T.R.; Hislop, G.W., "Holistic Software Engineering Education Based on a Humanitarian Open Source Project," in Software Engineering Education & Training, 2007. CSEET '07. 20th Conference on , vol., no., pp.327-335, 3-5 July 2007. DOI=http://dx.doi.org/10.1109/CSEET.2007.26<br />
<br />
* Morelli, R.A., Ellis, H.J.C., de Lanerolle, T., Damon, J., and Walti, C., “Can Student-Written Software Help Sustain Humanitarian FOSS?”, The 4th International Conference on Information Systems for Crisis Response and Management, Delft, the Netherlands, May 2007, pp. 41-44. PDF:http://www.cs.trincoll.edu/~ram/ram/MorelliEtAl_ISCRAM07.pdf<br />
<br />
* Heidi J. C. Ellis, Ralph A. Morelli, Trishan R. de Lanerolle, Jonathan Damon, and Jonathan Raye. 2007. Can humanitarian open-source software development draw new students to CS?. SIGCSE Bull. 39, 1 (March 2007), 551-555. DOI=http://dx.doi.org/10.1145/1227504.1227495<br />
<br />
<br />
Conferences<br />
* Hislop, Gregory W. and Ellis, Heidi J. C. (2016). Building the Student Pipeline to Open Source Communities using HFOSS. 2016 Red Hat Summit.<br />
<br />
* Ellis, Heidi J. C. and Hislop, Gregory W. (2016). Want Students Ready to Contribute? Let’s Discuss What They Should Know!. 2016 OSCON Everything Open Conference.<br />
<br />
== Panels and Posters ==<br />
<br />
* Weiss, Stewart and Klukowska, Joanna and Burge, Darci (2017). Injecting Open Source Content Into CS2/Data Structures Courses (poster). 22nd Annual Consortium For Computing Sciences in Colleges, Northeastern Conference. <br />
<br />
* Murphy, Christian and Buffardi, Kevin and Dehlinger, Josh and Lambert, Lynn, and Veilleux, Nanette (2017). Community Engagement with Free and Open Source Software (panel). 48th ACM SIGCSE Technical Symposium on Computer Science Education.<br />
<br />
* Ellis, Heidi J. C. and Hislop, Gregory W. and Burdge, Darci and Postner, Lori and Jackson, Stoney (2016). Learning via Student Participation in Humanitarian Free and Open Source Software Projects. NSF/AAAS conference on Envisioning the Future of Undergraduate STEM Education: Research and Practice.<br />
<br />
* Ellis, Heidi J. C. and Hislop, Gregory W. and Burdge, Darci and Postner, Lori and Jackson, Stoney and Kussmaul, Clif (2016). OpenPath – Improving Student Pathways to Computing Professions via Humanitarian Free and Open Source Software. NSF/AAAS conference on Envisioning the Future of Undergraduate STEM Education: Research and Practice.<br />
<br />
* Jackson, Stoney and Ellis, Heidi J. C. and Hislop, Gregory W. and Postner, Lori and Jackson, Stoney (2015). Team Project Experiences in Humanitarian Free and Open Source Software (HFOSS): Faculty Poster Abstract. J. Comput. Sci. Coll. USA.<br />
<br />
* Alkoby, Karen and Burdge, Darci and Morgan, Becka and Ordonez, Patti and Likins, Gina (2015). Humanitarian Free and Open Source Software: Motivating the Underrepresented. Grace Hopper Celebration of Women in Computing 2015.<br />
<br />
* Pulimood, S. M., Hislop, G.W., and Ellis, H.J.C., “A Multi-Institutional Study of Self-Perceived Learning via Student Involvement in HFOSS Projects,” Poster. CCSC-EA, Atlantic City NJ, Oct. 2015.<br />
<br />
* Gregory W. Hislop and Heidi J.C. Ellis. 2015. Practical Experiences for IT Students in Humanitarian Free and Open Source Software Projects. In Proceedings of the 16th Annual Conference on Information Technology Education (SIGITE '15). ACM, New York, NY, USA, 99-99. DOI=http://dx.doi.org/10.1145/2808006.2808042 <br />
<br />
* Gregory W. Hislop, Stoney Jackson, and Heidi J.C. Ellis. 2015. FOSS Artifacts for Evaluating Students on Team Projects. In Proceedings of the 16th Annual Conference on Information Technology Education (SIGITE '15). ACM, New York, NY, USA, 57-57. DOI=http://dx.doi.org/10.1145/2808006.2808009 <br />
<br />
* Jackson, S., Ellis H.J.C., Hislop, G.W., and Postner, L., “Team project experiences in humanitarian free and open source software (HFOSS)”: faculty poster abstract. J. Comput. Sci. Coll (CCSCNE '15). 30, 6 (June 2015), 156-157.<br />
<br />
* Ellis, H.J.C., Burdge, D., Morgan, R., Ordóñez, P. and Alkoby, K., “Using Humanitarian Free and Open Source Software (HFOSS) to Attract the Underrepresented to Computer Science,” 2015 ACM Richard Tapia Celebration of Diversity in Computing, Boston, MA. Panel.<br />
<br />
* Heidi J.C. Ellis and Gregory W. Hislop. 2014. Structuring software engineering learning within open source software participation. In Proceedings of the 2014 conference on Innovation & technology in computer science education (ITiCSE '14). ACM, New York, NY, USA, 326-326. DOI=http://dx.doi.org/10.1145/2591708.2602681 <br />
<br />
* Heidi J.C. Ellis, Gregory W. Hislop, and Joanmarie Diggs. 2013. Developing HFOSS projects using integrated teams across levels and institutions. In Proceedings of the 18th ACM conference on Innovation and technology in computer science education (ITiCSE '13). ACM, New York, NY, USA, 349-349. DOI=http://dx.doi.org/10.1145/2462476.2465613 <br />
<br />
* Heidi J.C. Ellis, Stoney Jackson, Darci Burdge, Lori Postner, Gregory W. Hislop, and Joanmarie Diggs. 2014. Learning within a professional environment: shared ownership of an HFOSS project. In Proceedings of the 2014 conference on Innovation & technology in computer science education (ITiCSE '14). ACM, New York, NY, USA, 337-337. DOI=http://dx.doi.org/10.1145/2591708.2602660 <br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Purcell, M.; Chua, M.; Dziallas, S., "Towards a model of faculty development for FOSS in education," in Software Engineering Education and Training (CSEE&T), 2013 IEEE 26th Conference on , vol., no., pp.269-273, 19-21 May 2013. DOI=http://dx.doi.org/10.1109/CSEET.2013.6595259<br />
<br />
* Purcell, M., Ellis, H.J.C., and Hislop, G.W. (2013). An Approach for Evaluating Open Source Projects for Student Participation. Poster at CCSC NE.<br />
<br />
* Ellis, H.J.C., and Hislop, G.W. (2013). Community-Based Student Learning via Participation in Humanitarian FOSS Projects. Poster at CCSC NE.<br />
<br />
*Ellis, H.J.C.,, Hislop, G.W., and Morelli, R.A., “SoftHum: Student Participation in the Community of Open Source Software for Humanity,” Poster, 2013 NSF/AASE Conference for Principle Investigators of the Transforming Undergraduate Education STEM program, January 23-25, 2013 Washington, D.C. <br />
<br />
* Ellis, H.J.C.,, Hislop, G.W., and Morelli, R.A., “HumIT: Student IT Services to Support Open Source Software for Humanity,” Poster, 2013 NSF/AASE Conference for Principle Investigators of the Transforming Undergraduate Education STEM program, January 23-25, 2013 Washington, D.C. <br />
<br />
* Clif Kussmaul, Heidi J.C. Ellis, and Gregory W. Hislop. 2012. 50 ways to be a FOSSer: simple ways to involve students & faculty (abstract only). In Proceedings of the 43rd ACM technical symposium on Computer Science Education (SIGCSE '12). ACM, New York, NY, USA, 671-671. DOI=http://dx.doi.org/10.1145/2157136.2157393 <br />
<br />
* Heidi J.C. Ellis and Gregory W. Hislop. 2011. Student IT services to support open source software for humanity. In Proceedings of the 2011 conference on Information technology education (SIGITE '11). ACM, New York, NY, USA, 307-308. DOI=http://dx.doi.org/10.1145/2047594.2047676 <br />
<br />
* Heidi J.C. Ellis, Gregory W. Hislop, and Ralph A. Morelli. 2011. A comparison of software engineering knowledge gained from student participation in humanitarian foss projects. In Proceedings of the 16th annual joint conference on Innovation and technology in computer science education (ITiCSE '11). ACM, New York, NY, USA, 360-360. DOI=http://dx.doi.org/10.1145/1999747.1999874 <br />
<br />
* Heidi J.C. Ellis and Gregory W. Hislop. 2011. Courseware: student learning via FOSS field trips. In Proceedings of the 16th annual joint conference on Innovation and technology in computer science education (ITiCSE '11). ACM, New York, NY, USA, 329-329. DOI=http://dx.doi.org/10.1145/1999747.1999840 <br />
<br />
* Heidi J.C. Ellis, Mel Chua, Matthew C. Jadud, and Gregory W. Hislop. 2011. Learning through open source participation. In Proceedings of the 42nd ACM technical symposium on Computer science education (SIGCSE '11). ACM, New York, NY, USA, 83-84. DOI=http://dx.doi.org/10.1145/1953163.1953191<br />
<br />
* Ellis, H.J.C., Hislop, G.W., and Morelli, R.A., “SoftHum: Student Participation in the Community of Open Source Software for Humanity,” Poster, NSF 2011 CCLI-TUES PIs Conference, Washington, DC, Jan. 26-28, 2011.<br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Chua, M.; Kussmaul, Clif; Burke, Matthew M., "Panel — Teaching students to participate in Open Source Software projects," in Frontiers in Education Conference (FIE), 2010 IEEE , vol., no., pp.F2B-1-F2B-2, 27-30 Oct. 2010. DOI=http://dx.doi.org/10.1109/FIE.2010.5673437<br />
<br />
* Bonhomme-Biais, A., Ellis, H.J.C., Lockwood, J., and Raschid, L., “Open Source for Good” Panel, Grace Hopper Celebration of Women in Computing, Washington, DC, Oct. 2010<br />
<br />
* Hislop, G.W., Ellis, H.J.C., DeKoenigsburg, G., and Jazayeri, D., “Student Participation in OSS Projects,” The 6th International Conference on Open Source Systems, Notre Dame, IN, June, 2010.<br />
<br />
* Heidi J. C. Ellis, Gregory W. Hislop, Ralph Morelli, and Norman Danner. 2010. Instructional aspects of student participation in humanitarian Free and Open Source Software: panel discussion. J. Comput. Sci. Coll. 25, 6 (June 2010), 152-154. <br />
<br />
* Ellis, H.J.C., Hislop, G.W., and Ibanez, L., “Opportunities for Students to Contribute to FOSS Projects,” O’Reilly Open Source Convention (OSCON), Portland, OR, July 19-23, 2010. [[http://cdn.oreillystatic.com/en/assets/1/event/45/Opportunities%20for%20Students%20to%20Contribute%20to%20FOSS%20Projects%20Presentation.odp .ODP]]<br />
<br />
== Related Efforts ==<br />
<br />
* Murphy, Christian and Weng, Judy and Pearce, Jan and Veilleux, Nanette (2017). Addressing Diversity &amp; Inclusion Issues in Computer Science through Contributions to Free and Open Source Software (Birds of a Feather). 2017 ACM Richard Tapia Celebration of Diversity in Computing.<br />
<br />
* Ellis, Heidi J.C. and Jackson, Stoney and Hislop, Gregory W. and Pulimood, S. Monisha and Likins, Gina (2016). Preparing to Teach Humanitarian Open Source (Abstract Only). Proceedings of the 47th ACM Technical Symposium on Computing Science Education. New York, NY, USA. Birds of a Feather Session (BoF) at SIGCSE Symposium.<br />
<br />
* Rebelsky, Sam A. and Morgan, Becka and Pulimood, S. Monisha and Postner, Lori and Hislop, Gregory W. (2015). Incorporating Humanitarian Free and Open Source Software in CS Classrooms. Grace Hopper Celebration of Women in Computing 2015. Birds of a Feather Session (BoF).<br />
<br />
* Postner, L., Jackson, S., Coleman, B., MelloStark, S., Rebelsky, S. (2015). Student Contributions to Humanitarian Free and Open Source Software (HFOSS). Birds of a Feather Session and abstract at SIGCSE 2015 Symposium.<br />
<br />
* Gregory W. Hislop, Heidi J.C. Ellis, Darci Burdge, Sean Goggins, Lori Postner, and Stoney Jackson. 2013. Encouraging faculty & student involvement in humanitarian free and open source software (HFOSS)(abstract only). In Proceeding of the 44th ACM technical symposium on Computer science education (SIGCSE '13). ACM, New York, NY, USA, 751-751. DOI=http://dx.doi.org/10.1145/2445196.2445481 <br />
<br />
* Wurst, K., Postner, L., and Jackson, S. (2014). Teaching Open Source (Software). Birds of a Feather Session (BoF) at SIGCSE Symposium.<br />
<br />
== Workshops ==<br />
* Burdge, Darci and Jackson, Stoney (2016). Git 101: Foundations for a Common Workflow to Contribute to HFOSS: Tutorial Presentation. J. Comput. Sci. Coll. 31 (6), 18-20. <br />
<br />
* Burdge, Darci and Jackson, Stoney (2016). Git 102: A Common Workflow to Contribute to HFOSS: Tutorial Presentation. J. Comput. Sci. Coll. 31 (6), 34-36.<br />
<br />
* Ellis, H.J.C., Jackson, S., Hislop, G.W., Postner, L., and Burdge, D. (2014). Getting Started in Open Source - A Tour of a Real Project. Workshop at CCSC NE.<br />
<br />
* Hislop, G.W., Burdge, D., Postner, L., and Ellis H.J.C (2013). Preparing for Student Participation in HFOSS Projects - FOSS Tools and Techniques. Workshop at CCSC E.<br />
<br />
* Ellis, H.J.C., and Hislop, G.W. (2013). Project Selection for Student Participation in Humanitarian FOSS. Workshop at the 26th Annual Conference on Software Engineering Education and Training (SIGITE).<br />
<br />
* Ellis, H.J.C., Hislop, G.W., and Purcell, M. (2013). Project Selection for Student Involvement in Humanitarian FOSS. Workshop at 26th Annual Conference on Software Engineering Education and Training (CSEET). San Francisco.<br />
<br />
* Ellis, H.J.C., Hislop, G.W., Purcell, M., and Postner, L. (2013). Project Selection for Student Participation in Humanitarian FOSS. Workshop at CCSC NE.<br />
<br />
* Ellis, H.J.C., and Hislop, G.W., “Project Selection for Student Participation in Humanitarian FOSS,” 26th Annual Conference on Software Engineering Education and Training, San Francisco, May. 2013<br />
<br />
* Ellis, H.J.C., and Hislop, G.W., “Student Participation in Humanitarian Open Source Software (HFOSS),” Lightening Talk, 2011 International Computing Education Research Workshop, Providence, RI, August, 2011. <br />
<br />
* Morelli, R.A., Danner, N., Iyengar, J., de Lanerolle, T. R., and Ellis, H.J.C., “Teaching and Building Humanitarian Open Source Software,” SIGCSE 2008, Technical Symposium on Computer Science Education, Portland OR, Mar. 2008.<br />
<br />
* Morelli, R.A., Danner, N., Iyengar, J., de Lanerolle, T. R., and Ellis, H.J.C., “Teaching and Building Humanitarian Open Source Software,” SIGCSE 2008, Technical Symposium on Computer Science Education, Portland OR, Mar. 2008.<br />
<br />
<br />
[[Category:Reference]]</div>Cmurphyhttp://www.foss2serve.org/index.php/PublicationsPublications2017-09-25T02:32:45Z<p>Cmurphy: /* Related Efforts */</p>
<hr />
<div><br />
This page contains references to publications and events that are related to the effort to help students contribute to HFOSS.<br />
<br />
== Papers ==<br />
Journals<br />
* Hislop, Gregory W. and Jackson, Stoney and Ellis, Heidi J.C. (2015). FOSS Artifacts for Evaluating Students on Team Projects. Proceedings of the 16th Annual Conference on Information Technology Education. New York, NY, USA.<br />
<br />
* Hislop, Gregory W. and Ellis, Heidi J.C. (2015). Practical Experiences for IT Students in Humanitarian Free and Open Source Software Projects. Proceedings of the 16th Annual Conference on Information Technology Education. New York, NY, USA.<br />
<br />
* Heidi J. C. Ellis, Gregory W. Hislop, Stoney Jackson, and Lori Postner. 2015. Team Project Experiences in Humanitarian Free and Open Source Software (HFOSS). Trans. Comput. Educ. 15, 4, Article 18 (December 2015), 23 pages. DOI=http://dx.doi.org/10.1145/2684812 <br />
<br />
* Gregory W. Hislop, Heidi J.C. Ellis, S. Monisha Pulimood, Becka Morgan, Suzanne Mello-Stark, Ben Coleman, and Cam Macdonell. 2015. A Multi-Institutional Study of Learning via Student Involvement in Humanitarian Free and Open Source Software Projects. In Proceedings of the eleventh annual International Conference on International Computing Education Research (ICER '15). ACM, New York, NY, USA, 199-206. DOI=http://dx.doi.org/10.1145<br />
<br />
* Ellis, H. J. C., & Hislop, G. W., & Pulimood, S. M., & Morgan, B., & Coleman, B. (2015, June), Software Engineering Learning in HFOSS: A Multi-Institutional Study Paper presented at 2015 ASEE Annual Conference and Exposition, Seattle, Washington. DOI=http://dx.doi.org/10.18260/p.24716<br />
<br />
* Jackson, S., Ellis, H. (2015). Supporting HFOSS using Scrum in a Capstone Course. Abstract and presentation for SIGCAS Symposium on Computing for Social Good. SIGCAS Comput. Soc. 45, 2 (July 2015). <br />
<br />
* Postner, L., Jackson, S., Ellis, H., Hislop, G., Burdge, D., and Goggins, S. (2015). Using Humanitarian Free and Open Source Software (HFOSS) to Introduce Computing for the Social Good. Abstract and presentation for SIGCAS Symposium on Computing for Social Good. SIGCAS Comput. Soc. 45, 2 (July 2015), 3535.<br />
<br />
* Heidi J.C. Ellis, Stoney Jackson, Darci Burdge, Lori Postner, Gregory W. Hislop, and Joanie Diggs. 2014. Learning within a professional environment: shared ownership of an HFOSS project. In Proceedings of the 15th Annual Conference on Information technology education (SIGITE '14). ACM, New York, NY, USA, 95-100. DOI=http://dx.doi.org/10.1145/2656450.2656468 <br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Purcell, M.; Chua, M.; Dziallas, S., "Towards a model of faculty development for FOSS in education," in Software Engineering Education and Training (CSEE&T), 2013 IEEE 26th Conference on , vol., no., pp.269-273, 19-21 May 2013. DOI=http://dx.doi.org/10.1109/CSEET.2013.6595259<br />
<br />
* Ellis, H. J., & Hislop, G. W., & Rodriguez, J. S., & Morelli, R. (2012, June), Student Software Engineering Learning via Participation in Humanitarian FOSS Projects Paper presented at 2012 ASEE Annual Conference, San Antonio, Texas. https://peer.asee.org/21949<br />
<br />
* Heidi J.C. Ellis, Michelle Purcell, and Gregory W. Hislop. 2012. An approach for evaluating FOSS projects for student participation. In Proceedings of the 43rd ACM technical symposium on Computer Science Education (SIGCSE '12). ACM, New York, NY, USA, 415-420. DOI=http://dx.doi.org/10.1145/2157136.2157260<br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Chua, M.; Dziallas, S., "How to involve students in FOSS projects," in Frontiers in Education Conference (FIE), 2011 , vol., no., pp.T1H-1-T1H-6, 12-15 Oct. 2011. DOI=http://dx.doi.org/10.1109/FIE.2011.6142994<br />
<br />
* Ralph Morelli, Allen Tucker, Norman Danner, Trishan R. De Lanerolle, Heidi J. C. Ellis, Ozgur Izmirli, Danny Krizanc, and Gary Parker. 2009. Revitalizing computing education through free and open source software for humanity. Commun. ACM 52, 8 (August 2009), 67-75. DOI=http://doi.acm.org/10.1145/1536616.1536635 <br />
<br />
* Gregory W. Hislop, Heidi J.C. Ellis, and Ralph A. Morelli. 2009. Evaluating student experiences in developing software for humanity. SIGCSE Bull. 41, 3 (July 2009), 263-267. DOI=http://dx.doi.org/10.1145/1595496.1562959 <br />
<br />
* Ellis, H.J.C.; Morelli, R.A.; Hislop, G.W., "Work in progress - challenges to educating students within the Community of Open Source Software for Humanity," in Frontiers in Education Conference, 2008. FIE 2008. 38th Annual , vol., no., pp.S3H-7-S3H-8, 22-25 Oct. 2008. DOI=http://dx.doi.org/10.1109/FIE.2008.4720515<br />
<br />
* Ellis, H.; Morelli, R.A.; Hislop, G.W., "Support for Educating Software Engineers Through Humanitarian Open Source Projects," in Software Engineering Education and Training Workshop, 2008. CSEETW '08. 21st IEEE-CS Conference on , vol., no., pp.1-4, 14-17 April 2008. DOI=http://dx.doi.org/10.1109/CSEETW.2008.5<br />
<br />
* Ellis, H.J.C.; Hislop, G.W., "Fostering the Community of Software Engineering Educators," in Software Engineering Education and Training, 2008. CSEET '08. IEEE 21st Conference on , vol., no., pp.233-237, 14-17 April 2008. DOI=http://dx.doi.org/10.1109/CSEET.2008.18<br />
<br />
* Ellis, H.J.C.; Morelli, R.A.; de Lanerolle, T.R.; Hislop, G.W., "Holistic Software Engineering Education Based on a Humanitarian Open Source Project," in Software Engineering Education & Training, 2007. CSEET '07. 20th Conference on , vol., no., pp.327-335, 3-5 July 2007. DOI=http://dx.doi.org/10.1109/CSEET.2007.26<br />
<br />
* Morelli, R.A., Ellis, H.J.C., de Lanerolle, T., Damon, J., and Walti, C., “Can Student-Written Software Help Sustain Humanitarian FOSS?”, The 4th International Conference on Information Systems for Crisis Response and Management, Delft, the Netherlands, May 2007, pp. 41-44. PDF:http://www.cs.trincoll.edu/~ram/ram/MorelliEtAl_ISCRAM07.pdf<br />
<br />
* Heidi J. C. Ellis, Ralph A. Morelli, Trishan R. de Lanerolle, Jonathan Damon, and Jonathan Raye. 2007. Can humanitarian open-source software development draw new students to CS?. SIGCSE Bull. 39, 1 (March 2007), 551-555. DOI=http://dx.doi.org/10.1145/1227504.1227495<br />
<br />
<br />
Conferences<br />
* Hislop, Gregory W. and Ellis, Heidi J. C. (2016). Building the Student Pipeline to Open Source Communities using HFOSS. 2016 Red Hat Summit.<br />
<br />
* Ellis, Heidi J. C. and Hislop, Gregory W. (2016). Want Students Ready to Contribute? Let’s Discuss What They Should Know!. 2016 OSCON Everything Open Conference.<br />
<br />
== Panels and Posters ==<br />
<br />
* Weiss, Stewart and Klukowska, Joanna and Burge, Darci (2017). Injecting Open Source Content Into CS2/Data Structures Courses (poster). 22nd Annual Consortium For Computing Sciences in Colleges, Northeastern Conference. <br />
<br />
* Murphy, Christian and Buffardi, Kevin and Dehlinger, Josh and Lambert, Lynn, and Veilleux, Nanette (2017). Community Engagement with Free and Open Source Software (panel). 48th ACM SIGCSE Technical Symposium on Computer Science Education.<br />
<br />
* Ellis, Heidi J. C. and Hislop, Gregory W. and Burdge, Darci and Postner, Lori and Jackson, Stoney (2016). Learning via Student Participation in Humanitarian Free and Open Source Software Projects. NSF/AAAS conference on Envisioning the Future of Undergraduate STEM Education: Research and Practice.<br />
<br />
* Ellis, Heidi J. C. and Hislop, Gregory W. and Burdge, Darci and Postner, Lori and Jackson, Stoney and Kussmaul, Clif (2016). OpenPath – Improving Student Pathways to Computing Professions via Humanitarian Free and Open Source Software. NSF/AAAS conference on Envisioning the Future of Undergraduate STEM Education: Research and Practice.<br />
<br />
* Jackson, Stoney and Ellis, Heidi J. C. and Hislop, Gregory W. and Postner, Lori and Jackson, Stoney (2015). Team Project Experiences in Humanitarian Free and Open Source Software (HFOSS): Faculty Poster Abstract. J. Comput. Sci. Coll. USA.<br />
<br />
* Alkoby, Karen and Burdge, Darci and Morgan, Becka and Ordonez, Patti and Likins, Gina (2015). Humanitarian Free and Open Source Software: Motivating the Underrepresented. Grace Hopper Celebration of Women in Computing 2015.<br />
<br />
* Pulimood, S. M., Hislop, G.W., and Ellis, H.J.C., “A Multi-Institutional Study of Self-Perceived Learning via Student Involvement in HFOSS Projects,” Poster. CCSC-EA, Atlantic City NJ, Oct. 2015.<br />
<br />
* Gregory W. Hislop and Heidi J.C. Ellis. 2015. Practical Experiences for IT Students in Humanitarian Free and Open Source Software Projects. In Proceedings of the 16th Annual Conference on Information Technology Education (SIGITE '15). ACM, New York, NY, USA, 99-99. DOI=http://dx.doi.org/10.1145/2808006.2808042 <br />
<br />
* Gregory W. Hislop, Stoney Jackson, and Heidi J.C. Ellis. 2015. FOSS Artifacts for Evaluating Students on Team Projects. In Proceedings of the 16th Annual Conference on Information Technology Education (SIGITE '15). ACM, New York, NY, USA, 57-57. DOI=http://dx.doi.org/10.1145/2808006.2808009 <br />
<br />
* Jackson, S., Ellis H.J.C., Hislop, G.W., and Postner, L., “Team project experiences in humanitarian free and open source software (HFOSS)”: faculty poster abstract. J. Comput. Sci. Coll (CCSCNE '15). 30, 6 (June 2015), 156-157.<br />
<br />
* Ellis, H.J.C., Burdge, D., Morgan, R., Ordóñez, P. and Alkoby, K., “Using Humanitarian Free and Open Source Software (HFOSS) to Attract the Underrepresented to Computer Science,” 2015 ACM Richard Tapia Celebration of Diversity in Computing, Boston, MA. Panel.<br />
<br />
* Heidi J.C. Ellis and Gregory W. Hislop. 2014. Structuring software engineering learning within open source software participation. In Proceedings of the 2014 conference on Innovation & technology in computer science education (ITiCSE '14). ACM, New York, NY, USA, 326-326. DOI=http://dx.doi.org/10.1145/2591708.2602681 <br />
<br />
* Heidi J.C. Ellis, Gregory W. Hislop, and Joanmarie Diggs. 2013. Developing HFOSS projects using integrated teams across levels and institutions. In Proceedings of the 18th ACM conference on Innovation and technology in computer science education (ITiCSE '13). ACM, New York, NY, USA, 349-349. DOI=http://dx.doi.org/10.1145/2462476.2465613 <br />
<br />
* Heidi J.C. Ellis, Stoney Jackson, Darci Burdge, Lori Postner, Gregory W. Hislop, and Joanmarie Diggs. 2014. Learning within a professional environment: shared ownership of an HFOSS project. In Proceedings of the 2014 conference on Innovation & technology in computer science education (ITiCSE '14). ACM, New York, NY, USA, 337-337. DOI=http://dx.doi.org/10.1145/2591708.2602660 <br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Purcell, M.; Chua, M.; Dziallas, S., "Towards a model of faculty development for FOSS in education," in Software Engineering Education and Training (CSEE&T), 2013 IEEE 26th Conference on , vol., no., pp.269-273, 19-21 May 2013. DOI=http://dx.doi.org/10.1109/CSEET.2013.6595259<br />
<br />
* Purcell, M., Ellis, H.J.C., and Hislop, G.W. (2013). An Approach for Evaluating Open Source Projects for Student Participation. Poster at CCSC NE.<br />
<br />
* Ellis, H.J.C., and Hislop, G.W. (2013). Community-Based Student Learning via Participation in Humanitarian FOSS Projects. Poster at CCSC NE.<br />
<br />
*Ellis, H.J.C.,, Hislop, G.W., and Morelli, R.A., “SoftHum: Student Participation in the Community of Open Source Software for Humanity,” Poster, 2013 NSF/AASE Conference for Principle Investigators of the Transforming Undergraduate Education STEM program, January 23-25, 2013 Washington, D.C. <br />
<br />
* Ellis, H.J.C.,, Hislop, G.W., and Morelli, R.A., “HumIT: Student IT Services to Support Open Source Software for Humanity,” Poster, 2013 NSF/AASE Conference for Principle Investigators of the Transforming Undergraduate Education STEM program, January 23-25, 2013 Washington, D.C. <br />
<br />
* Clif Kussmaul, Heidi J.C. Ellis, and Gregory W. Hislop. 2012. 50 ways to be a FOSSer: simple ways to involve students & faculty (abstract only). In Proceedings of the 43rd ACM technical symposium on Computer Science Education (SIGCSE '12). ACM, New York, NY, USA, 671-671. DOI=http://dx.doi.org/10.1145/2157136.2157393 <br />
<br />
* Heidi J.C. Ellis and Gregory W. Hislop. 2011. Student IT services to support open source software for humanity. In Proceedings of the 2011 conference on Information technology education (SIGITE '11). ACM, New York, NY, USA, 307-308. DOI=http://dx.doi.org/10.1145/2047594.2047676 <br />
<br />
* Heidi J.C. Ellis, Gregory W. Hislop, and Ralph A. Morelli. 2011. A comparison of software engineering knowledge gained from student participation in humanitarian foss projects. In Proceedings of the 16th annual joint conference on Innovation and technology in computer science education (ITiCSE '11). ACM, New York, NY, USA, 360-360. DOI=http://dx.doi.org/10.1145/1999747.1999874 <br />
<br />
* Heidi J.C. Ellis and Gregory W. Hislop. 2011. Courseware: student learning via FOSS field trips. In Proceedings of the 16th annual joint conference on Innovation and technology in computer science education (ITiCSE '11). ACM, New York, NY, USA, 329-329. DOI=http://dx.doi.org/10.1145/1999747.1999840 <br />
<br />
* Heidi J.C. Ellis, Mel Chua, Matthew C. Jadud, and Gregory W. Hislop. 2011. Learning through open source participation. In Proceedings of the 42nd ACM technical symposium on Computer science education (SIGCSE '11). ACM, New York, NY, USA, 83-84. DOI=http://dx.doi.org/10.1145/1953163.1953191<br />
<br />
* Ellis, H.J.C., Hislop, G.W., and Morelli, R.A., “SoftHum: Student Participation in the Community of Open Source Software for Humanity,” Poster, NSF 2011 CCLI-TUES PIs Conference, Washington, DC, Jan. 26-28, 2011.<br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Chua, M.; Kussmaul, Clif; Burke, Matthew M., "Panel — Teaching students to participate in Open Source Software projects," in Frontiers in Education Conference (FIE), 2010 IEEE , vol., no., pp.F2B-1-F2B-2, 27-30 Oct. 2010. DOI=http://dx.doi.org/10.1109/FIE.2010.5673437<br />
<br />
* Bonhomme-Biais, A., Ellis, H.J.C., Lockwood, J., and Raschid, L., “Open Source for Good” Panel, Grace Hopper Celebration of Women in Computing, Washington, DC, Oct. 2010<br />
<br />
* Hislop, G.W., Ellis, H.J.C., DeKoenigsburg, G., and Jazayeri, D., “Student Participation in OSS Projects,” The 6th International Conference on Open Source Systems, Notre Dame, IN, June, 2010.<br />
<br />
* Heidi J. C. Ellis, Gregory W. Hislop, Ralph Morelli, and Norman Danner. 2010. Instructional aspects of student participation in humanitarian Free and Open Source Software: panel discussion. J. Comput. Sci. Coll. 25, 6 (June 2010), 152-154. <br />
<br />
* Ellis, H.J.C., Hislop, G.W., and Ibanez, L., “Opportunities for Students to Contribute to FOSS Projects,” O’Reilly Open Source Convention (OSCON), Portland, OR, July 19-23, 2010. [[http://cdn.oreillystatic.com/en/assets/1/event/45/Opportunities%20for%20Students%20to%20Contribute%20to%20FOSS%20Projects%20Presentation.odp .ODP]]<br />
<br />
== Related Efforts ==<br />
<br />
* Murphy, Christian and Weng, Judy and Pearce, Jan and Veilleux, Nanette (2017). Addressing Diversity &amp; Inclusion Issues in Computer Science through Contributions to Free and Open Source Software (Birds of a Feather). 2017 ACM Richard Tapia Celebration of Diversity in Computing.<br />
<br />
* Ellis, Heidi J.C. and Jackson, Stoney and Hislop, Gregory W. and Pulimood, S. Monisha and Likins, Gina (2016). Preparing to Teach Humanitarian Open Source (Abstract Only). Proceedings of the 47th ACM Technical Symposium on Computing Science Education. New York, NY, USA. Birds of a Feather Session (BoF) at SIGCSE Symposium.<br />
<br />
* Rebelsky, Sam A. and Morgan, Becka and Pulimood, S. Monisha and Postner, Lori and Hislop, Gregory W. (2015). Incorporating Humanitarian Free and Open Source Software in CS Classrooms. Grace Hopper Celebration of Women in Computing 2015. Birds of a Feather Session (BoF).<br />
<br />
* Postner, L., Jackson, S., Coleman, B., MelloStark, S., Rebelsky, S. (2015). Student Contributions to Humanitarian Free and Open Source Software (HFOSS). Birds of a Feather Session and abstract at SIGCSE 2015 Symposium.<br />
<br />
* Gregory W. Hislop, Heidi J.C. Ellis, Darci Burdge, Sean Goggins, Lori Postner, and Stoney Jackson. 2013. Encouraging faculty & student involvement in humanitarian free and open source software (HFOSS)(abstract only). In Proceeding of the 44th ACM technical symposium on Computer science education (SIGCSE '13). ACM, New York, NY, USA, 751-751. DOI=http://dx.doi.org/10.1145/2445196.2445481 <br />
<br />
* Wurst, K., Postner, L., and Jackson, S. (2014). Teaching Open Source (Software). Birds of a Feather Session (BoF) at SISCSE Symposium.<br />
<br />
== Workshops ==<br />
* Burdge, Darci and Jackson, Stoney (2016). Git 101: Foundations for a Common Workflow to Contribute to HFOSS: Tutorial Presentation. J. Comput. Sci. Coll. 31 (6), 18-20. <br />
<br />
* Burdge, Darci and Jackson, Stoney (2016). Git 102: A Common Workflow to Contribute to HFOSS: Tutorial Presentation. J. Comput. Sci. Coll. 31 (6), 34-36.<br />
<br />
* Ellis, H.J.C., Jackson, S., Hislop, G.W., Postner, L., and Burdge, D. (2014). Getting Started in Open Source - A Tour of a Real Project. Workshop at CCSC NE.<br />
<br />
* Hislop, G.W., Burdge, D., Postner, L., and Ellis H.J.C (2013). Preparing for Student Participation in HFOSS Projects - FOSS Tools and Techniques. Workshop at CCSC E.<br />
<br />
* Ellis, H.J.C., and Hislop, G.W. (2013). Project Selection for Student Participation in Humanitarian FOSS. Workshop at the 26th Annual Conference on Software Engineering Education and Training (SIGITE).<br />
<br />
* Ellis, H.J.C., Hislop, G.W., and Purcell, M. (2013). Project Selection for Student Involvement in Humanitarian FOSS. Workshop at 26th Annual Conference on Software Engineering Education and Training (CSEET). San Francisco.<br />
<br />
* Ellis, H.J.C., Hislop, G.W., Purcell, M., and Postner, L. (2013). Project Selection for Student Participation in Humanitarian FOSS. Workshop at CCSC NE.<br />
<br />
* Ellis, H.J.C., and Hislop, G.W., “Project Selection for Student Participation in Humanitarian FOSS,” 26th Annual Conference on Software Engineering Education and Training, San Francisco, May. 2013<br />
<br />
* Ellis, H.J.C., and Hislop, G.W., “Student Participation in Humanitarian Open Source Software (HFOSS),” Lightening Talk, 2011 International Computing Education Research Workshop, Providence, RI, August, 2011. <br />
<br />
* Morelli, R.A., Danner, N., Iyengar, J., de Lanerolle, T. R., and Ellis, H.J.C., “Teaching and Building Humanitarian Open Source Software,” SIGCSE 2008, Technical Symposium on Computer Science Education, Portland OR, Mar. 2008.<br />
<br />
* Morelli, R.A., Danner, N., Iyengar, J., de Lanerolle, T. R., and Ellis, H.J.C., “Teaching and Building Humanitarian Open Source Software,” SIGCSE 2008, Technical Symposium on Computer Science Education, Portland OR, Mar. 2008.<br />
<br />
<br />
[[Category:Reference]]</div>Cmurphyhttp://www.foss2serve.org/index.php/PublicationsPublications2017-09-25T02:32:33Z<p>Cmurphy: /* Panels and Posters */</p>
<hr />
<div><br />
This page contains references to publications and events that are related to the effort to help students contribute to HFOSS.<br />
<br />
== Papers ==<br />
Journals<br />
* Hislop, Gregory W. and Jackson, Stoney and Ellis, Heidi J.C. (2015). FOSS Artifacts for Evaluating Students on Team Projects. Proceedings of the 16th Annual Conference on Information Technology Education. New York, NY, USA.<br />
<br />
* Hislop, Gregory W. and Ellis, Heidi J.C. (2015). Practical Experiences for IT Students in Humanitarian Free and Open Source Software Projects. Proceedings of the 16th Annual Conference on Information Technology Education. New York, NY, USA.<br />
<br />
* Heidi J. C. Ellis, Gregory W. Hislop, Stoney Jackson, and Lori Postner. 2015. Team Project Experiences in Humanitarian Free and Open Source Software (HFOSS). Trans. Comput. Educ. 15, 4, Article 18 (December 2015), 23 pages. DOI=http://dx.doi.org/10.1145/2684812 <br />
<br />
* Gregory W. Hislop, Heidi J.C. Ellis, S. Monisha Pulimood, Becka Morgan, Suzanne Mello-Stark, Ben Coleman, and Cam Macdonell. 2015. A Multi-Institutional Study of Learning via Student Involvement in Humanitarian Free and Open Source Software Projects. In Proceedings of the eleventh annual International Conference on International Computing Education Research (ICER '15). ACM, New York, NY, USA, 199-206. DOI=http://dx.doi.org/10.1145<br />
<br />
* Ellis, H. J. C., & Hislop, G. W., & Pulimood, S. M., & Morgan, B., & Coleman, B. (2015, June), Software Engineering Learning in HFOSS: A Multi-Institutional Study Paper presented at 2015 ASEE Annual Conference and Exposition, Seattle, Washington. DOI=http://dx.doi.org/10.18260/p.24716<br />
<br />
* Jackson, S., Ellis, H. (2015). Supporting HFOSS using Scrum in a Capstone Course. Abstract and presentation for SIGCAS Symposium on Computing for Social Good. SIGCAS Comput. Soc. 45, 2 (July 2015). <br />
<br />
* Postner, L., Jackson, S., Ellis, H., Hislop, G., Burdge, D., and Goggins, S. (2015). Using Humanitarian Free and Open Source Software (HFOSS) to Introduce Computing for the Social Good. Abstract and presentation for SIGCAS Symposium on Computing for Social Good. SIGCAS Comput. Soc. 45, 2 (July 2015), 3535.<br />
<br />
* Heidi J.C. Ellis, Stoney Jackson, Darci Burdge, Lori Postner, Gregory W. Hislop, and Joanie Diggs. 2014. Learning within a professional environment: shared ownership of an HFOSS project. In Proceedings of the 15th Annual Conference on Information technology education (SIGITE '14). ACM, New York, NY, USA, 95-100. DOI=http://dx.doi.org/10.1145/2656450.2656468 <br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Purcell, M.; Chua, M.; Dziallas, S., "Towards a model of faculty development for FOSS in education," in Software Engineering Education and Training (CSEE&T), 2013 IEEE 26th Conference on , vol., no., pp.269-273, 19-21 May 2013. DOI=http://dx.doi.org/10.1109/CSEET.2013.6595259<br />
<br />
* Ellis, H. J., & Hislop, G. W., & Rodriguez, J. S., & Morelli, R. (2012, June), Student Software Engineering Learning via Participation in Humanitarian FOSS Projects Paper presented at 2012 ASEE Annual Conference, San Antonio, Texas. https://peer.asee.org/21949<br />
<br />
* Heidi J.C. Ellis, Michelle Purcell, and Gregory W. Hislop. 2012. An approach for evaluating FOSS projects for student participation. In Proceedings of the 43rd ACM technical symposium on Computer Science Education (SIGCSE '12). ACM, New York, NY, USA, 415-420. DOI=http://dx.doi.org/10.1145/2157136.2157260<br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Chua, M.; Dziallas, S., "How to involve students in FOSS projects," in Frontiers in Education Conference (FIE), 2011 , vol., no., pp.T1H-1-T1H-6, 12-15 Oct. 2011. DOI=http://dx.doi.org/10.1109/FIE.2011.6142994<br />
<br />
* Ralph Morelli, Allen Tucker, Norman Danner, Trishan R. De Lanerolle, Heidi J. C. Ellis, Ozgur Izmirli, Danny Krizanc, and Gary Parker. 2009. Revitalizing computing education through free and open source software for humanity. Commun. ACM 52, 8 (August 2009), 67-75. DOI=http://doi.acm.org/10.1145/1536616.1536635 <br />
<br />
* Gregory W. Hislop, Heidi J.C. Ellis, and Ralph A. Morelli. 2009. Evaluating student experiences in developing software for humanity. SIGCSE Bull. 41, 3 (July 2009), 263-267. DOI=http://dx.doi.org/10.1145/1595496.1562959 <br />
<br />
* Ellis, H.J.C.; Morelli, R.A.; Hislop, G.W., "Work in progress - challenges to educating students within the Community of Open Source Software for Humanity," in Frontiers in Education Conference, 2008. FIE 2008. 38th Annual , vol., no., pp.S3H-7-S3H-8, 22-25 Oct. 2008. DOI=http://dx.doi.org/10.1109/FIE.2008.4720515<br />
<br />
* Ellis, H.; Morelli, R.A.; Hislop, G.W., "Support for Educating Software Engineers Through Humanitarian Open Source Projects," in Software Engineering Education and Training Workshop, 2008. CSEETW '08. 21st IEEE-CS Conference on , vol., no., pp.1-4, 14-17 April 2008. DOI=http://dx.doi.org/10.1109/CSEETW.2008.5<br />
<br />
* Ellis, H.J.C.; Hislop, G.W., "Fostering the Community of Software Engineering Educators," in Software Engineering Education and Training, 2008. CSEET '08. IEEE 21st Conference on , vol., no., pp.233-237, 14-17 April 2008. DOI=http://dx.doi.org/10.1109/CSEET.2008.18<br />
<br />
* Ellis, H.J.C.; Morelli, R.A.; de Lanerolle, T.R.; Hislop, G.W., "Holistic Software Engineering Education Based on a Humanitarian Open Source Project," in Software Engineering Education & Training, 2007. CSEET '07. 20th Conference on , vol., no., pp.327-335, 3-5 July 2007. DOI=http://dx.doi.org/10.1109/CSEET.2007.26<br />
<br />
* Morelli, R.A., Ellis, H.J.C., de Lanerolle, T., Damon, J., and Walti, C., “Can Student-Written Software Help Sustain Humanitarian FOSS?”, The 4th International Conference on Information Systems for Crisis Response and Management, Delft, the Netherlands, May 2007, pp. 41-44. PDF:http://www.cs.trincoll.edu/~ram/ram/MorelliEtAl_ISCRAM07.pdf<br />
<br />
* Heidi J. C. Ellis, Ralph A. Morelli, Trishan R. de Lanerolle, Jonathan Damon, and Jonathan Raye. 2007. Can humanitarian open-source software development draw new students to CS?. SIGCSE Bull. 39, 1 (March 2007), 551-555. DOI=http://dx.doi.org/10.1145/1227504.1227495<br />
<br />
<br />
Conferences<br />
* Hislop, Gregory W. and Ellis, Heidi J. C. (2016). Building the Student Pipeline to Open Source Communities using HFOSS. 2016 Red Hat Summit.<br />
<br />
* Ellis, Heidi J. C. and Hislop, Gregory W. (2016). Want Students Ready to Contribute? Let’s Discuss What They Should Know!. 2016 OSCON Everything Open Conference.<br />
<br />
== Panels and Posters ==<br />
<br />
* Weiss, Stewart and Klukowska, Joanna and Burge, Darci (2017). Injecting Open Source Content Into CS2/Data Structures Courses (poster). 22nd Annual Consortium For Computing Sciences in Colleges, Northeastern Conference. <br />
<br />
* Murphy, Christian and Buffardi, Kevin and Dehlinger, Josh and Lambert, Lynn, and Veilleux, Nanette (2017). Community Engagement with Free and Open Source Software (panel). 48th ACM SIGCSE Technical Symposium on Computer Science Education.<br />
<br />
* Ellis, Heidi J. C. and Hislop, Gregory W. and Burdge, Darci and Postner, Lori and Jackson, Stoney (2016). Learning via Student Participation in Humanitarian Free and Open Source Software Projects. NSF/AAAS conference on Envisioning the Future of Undergraduate STEM Education: Research and Practice.<br />
<br />
* Ellis, Heidi J. C. and Hislop, Gregory W. and Burdge, Darci and Postner, Lori and Jackson, Stoney and Kussmaul, Clif (2016). OpenPath – Improving Student Pathways to Computing Professions via Humanitarian Free and Open Source Software. NSF/AAAS conference on Envisioning the Future of Undergraduate STEM Education: Research and Practice.<br />
<br />
* Jackson, Stoney and Ellis, Heidi J. C. and Hislop, Gregory W. and Postner, Lori and Jackson, Stoney (2015). Team Project Experiences in Humanitarian Free and Open Source Software (HFOSS): Faculty Poster Abstract. J. Comput. Sci. Coll. USA.<br />
<br />
* Alkoby, Karen and Burdge, Darci and Morgan, Becka and Ordonez, Patti and Likins, Gina (2015). Humanitarian Free and Open Source Software: Motivating the Underrepresented. Grace Hopper Celebration of Women in Computing 2015.<br />
<br />
* Pulimood, S. M., Hislop, G.W., and Ellis, H.J.C., “A Multi-Institutional Study of Self-Perceived Learning via Student Involvement in HFOSS Projects,” Poster. CCSC-EA, Atlantic City NJ, Oct. 2015.<br />
<br />
* Gregory W. Hislop and Heidi J.C. Ellis. 2015. Practical Experiences for IT Students in Humanitarian Free and Open Source Software Projects. In Proceedings of the 16th Annual Conference on Information Technology Education (SIGITE '15). ACM, New York, NY, USA, 99-99. DOI=http://dx.doi.org/10.1145/2808006.2808042 <br />
<br />
* Gregory W. Hislop, Stoney Jackson, and Heidi J.C. Ellis. 2015. FOSS Artifacts for Evaluating Students on Team Projects. In Proceedings of the 16th Annual Conference on Information Technology Education (SIGITE '15). ACM, New York, NY, USA, 57-57. DOI=http://dx.doi.org/10.1145/2808006.2808009 <br />
<br />
* Jackson, S., Ellis H.J.C., Hislop, G.W., and Postner, L., “Team project experiences in humanitarian free and open source software (HFOSS)”: faculty poster abstract. J. Comput. Sci. Coll (CCSCNE '15). 30, 6 (June 2015), 156-157.<br />
<br />
* Ellis, H.J.C., Burdge, D., Morgan, R., Ordóñez, P. and Alkoby, K., “Using Humanitarian Free and Open Source Software (HFOSS) to Attract the Underrepresented to Computer Science,” 2015 ACM Richard Tapia Celebration of Diversity in Computing, Boston, MA. Panel.<br />
<br />
* Heidi J.C. Ellis and Gregory W. Hislop. 2014. Structuring software engineering learning within open source software participation. In Proceedings of the 2014 conference on Innovation & technology in computer science education (ITiCSE '14). ACM, New York, NY, USA, 326-326. DOI=http://dx.doi.org/10.1145/2591708.2602681 <br />
<br />
* Heidi J.C. Ellis, Gregory W. Hislop, and Joanmarie Diggs. 2013. Developing HFOSS projects using integrated teams across levels and institutions. In Proceedings of the 18th ACM conference on Innovation and technology in computer science education (ITiCSE '13). ACM, New York, NY, USA, 349-349. DOI=http://dx.doi.org/10.1145/2462476.2465613 <br />
<br />
* Heidi J.C. Ellis, Stoney Jackson, Darci Burdge, Lori Postner, Gregory W. Hislop, and Joanmarie Diggs. 2014. Learning within a professional environment: shared ownership of an HFOSS project. In Proceedings of the 2014 conference on Innovation & technology in computer science education (ITiCSE '14). ACM, New York, NY, USA, 337-337. DOI=http://dx.doi.org/10.1145/2591708.2602660 <br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Purcell, M.; Chua, M.; Dziallas, S., "Towards a model of faculty development for FOSS in education," in Software Engineering Education and Training (CSEE&T), 2013 IEEE 26th Conference on , vol., no., pp.269-273, 19-21 May 2013. DOI=http://dx.doi.org/10.1109/CSEET.2013.6595259<br />
<br />
* Purcell, M., Ellis, H.J.C., and Hislop, G.W. (2013). An Approach for Evaluating Open Source Projects for Student Participation. Poster at CCSC NE.<br />
<br />
* Ellis, H.J.C., and Hislop, G.W. (2013). Community-Based Student Learning via Participation in Humanitarian FOSS Projects. Poster at CCSC NE.<br />
<br />
*Ellis, H.J.C.,, Hislop, G.W., and Morelli, R.A., “SoftHum: Student Participation in the Community of Open Source Software for Humanity,” Poster, 2013 NSF/AASE Conference for Principle Investigators of the Transforming Undergraduate Education STEM program, January 23-25, 2013 Washington, D.C. <br />
<br />
* Ellis, H.J.C.,, Hislop, G.W., and Morelli, R.A., “HumIT: Student IT Services to Support Open Source Software for Humanity,” Poster, 2013 NSF/AASE Conference for Principle Investigators of the Transforming Undergraduate Education STEM program, January 23-25, 2013 Washington, D.C. <br />
<br />
* Clif Kussmaul, Heidi J.C. Ellis, and Gregory W. Hislop. 2012. 50 ways to be a FOSSer: simple ways to involve students & faculty (abstract only). In Proceedings of the 43rd ACM technical symposium on Computer Science Education (SIGCSE '12). ACM, New York, NY, USA, 671-671. DOI=http://dx.doi.org/10.1145/2157136.2157393 <br />
<br />
* Heidi J.C. Ellis and Gregory W. Hislop. 2011. Student IT services to support open source software for humanity. In Proceedings of the 2011 conference on Information technology education (SIGITE '11). ACM, New York, NY, USA, 307-308. DOI=http://dx.doi.org/10.1145/2047594.2047676 <br />
<br />
* Heidi J.C. Ellis, Gregory W. Hislop, and Ralph A. Morelli. 2011. A comparison of software engineering knowledge gained from student participation in humanitarian foss projects. In Proceedings of the 16th annual joint conference on Innovation and technology in computer science education (ITiCSE '11). ACM, New York, NY, USA, 360-360. DOI=http://dx.doi.org/10.1145/1999747.1999874 <br />
<br />
* Heidi J.C. Ellis and Gregory W. Hislop. 2011. Courseware: student learning via FOSS field trips. In Proceedings of the 16th annual joint conference on Innovation and technology in computer science education (ITiCSE '11). ACM, New York, NY, USA, 329-329. DOI=http://dx.doi.org/10.1145/1999747.1999840 <br />
<br />
* Heidi J.C. Ellis, Mel Chua, Matthew C. Jadud, and Gregory W. Hislop. 2011. Learning through open source participation. In Proceedings of the 42nd ACM technical symposium on Computer science education (SIGCSE '11). ACM, New York, NY, USA, 83-84. DOI=http://dx.doi.org/10.1145/1953163.1953191<br />
<br />
* Ellis, H.J.C., Hislop, G.W., and Morelli, R.A., “SoftHum: Student Participation in the Community of Open Source Software for Humanity,” Poster, NSF 2011 CCLI-TUES PIs Conference, Washington, DC, Jan. 26-28, 2011.<br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Chua, M.; Kussmaul, Clif; Burke, Matthew M., "Panel — Teaching students to participate in Open Source Software projects," in Frontiers in Education Conference (FIE), 2010 IEEE , vol., no., pp.F2B-1-F2B-2, 27-30 Oct. 2010. DOI=http://dx.doi.org/10.1109/FIE.2010.5673437<br />
<br />
* Bonhomme-Biais, A., Ellis, H.J.C., Lockwood, J., and Raschid, L., “Open Source for Good” Panel, Grace Hopper Celebration of Women in Computing, Washington, DC, Oct. 2010<br />
<br />
* Hislop, G.W., Ellis, H.J.C., DeKoenigsburg, G., and Jazayeri, D., “Student Participation in OSS Projects,” The 6th International Conference on Open Source Systems, Notre Dame, IN, June, 2010.<br />
<br />
* Heidi J. C. Ellis, Gregory W. Hislop, Ralph Morelli, and Norman Danner. 2010. Instructional aspects of student participation in humanitarian Free and Open Source Software: panel discussion. J. Comput. Sci. Coll. 25, 6 (June 2010), 152-154. <br />
<br />
* Ellis, H.J.C., Hislop, G.W., and Ibanez, L., “Opportunities for Students to Contribute to FOSS Projects,” O’Reilly Open Source Convention (OSCON), Portland, OR, July 19-23, 2010. [[http://cdn.oreillystatic.com/en/assets/1/event/45/Opportunities%20for%20Students%20to%20Contribute%20to%20FOSS%20Projects%20Presentation.odp .ODP]]<br />
<br />
== Related Efforts ==<br />
* Ellis, Heidi J.C. and Jackson, Stoney and Hislop, Gregory W. and Pulimood, S. Monisha and Likins, Gina (2016). Preparing to Teach Humanitarian Open Source (Abstract Only). Proceedings of the 47th ACM Technical Symposium on Computing Science Education. New York, NY, USA. Birds of a Feather Session (BoF) at SIGCSE Symposium.<br />
<br />
* Rebelsky, Sam A. and Morgan, Becka and Pulimood, S. Monisha and Postner, Lori and Hislop, Gregory W. (2015). Incorporating Humanitarian Free and Open Source Software in CS Classrooms. Grace Hopper Celebration of Women in Computing 2015. Birds of a Feather Session (BoF).<br />
<br />
* Postner, L., Jackson, S., Coleman, B., MelloStark, S., Rebelsky, S. (2015). Student Contributions to Humanitarian Free and Open Source Software (HFOSS). Birds of a Feather Session and abstract at SIGCSE 2015 Symposium.<br />
<br />
* Gregory W. Hislop, Heidi J.C. Ellis, Darci Burdge, Sean Goggins, Lori Postner, and Stoney Jackson. 2013. Encouraging faculty & student involvement in humanitarian free and open source software (HFOSS)(abstract only). In Proceeding of the 44th ACM technical symposium on Computer science education (SIGCSE '13). ACM, New York, NY, USA, 751-751. DOI=http://dx.doi.org/10.1145/2445196.2445481 <br />
<br />
* Wurst, K., Postner, L., and Jackson, S. (2014). Teaching Open Source (Software). Birds of a Feather Session (BoF) at SISCSE Symposium.<br />
<br />
== Workshops ==<br />
* Burdge, Darci and Jackson, Stoney (2016). Git 101: Foundations for a Common Workflow to Contribute to HFOSS: Tutorial Presentation. J. Comput. Sci. Coll. 31 (6), 18-20. <br />
<br />
* Burdge, Darci and Jackson, Stoney (2016). Git 102: A Common Workflow to Contribute to HFOSS: Tutorial Presentation. J. Comput. Sci. Coll. 31 (6), 34-36.<br />
<br />
* Ellis, H.J.C., Jackson, S., Hislop, G.W., Postner, L., and Burdge, D. (2014). Getting Started in Open Source - A Tour of a Real Project. Workshop at CCSC NE.<br />
<br />
* Hislop, G.W., Burdge, D., Postner, L., and Ellis H.J.C (2013). Preparing for Student Participation in HFOSS Projects - FOSS Tools and Techniques. Workshop at CCSC E.<br />
<br />
* Ellis, H.J.C., and Hislop, G.W. (2013). Project Selection for Student Participation in Humanitarian FOSS. Workshop at the 26th Annual Conference on Software Engineering Education and Training (SIGITE).<br />
<br />
* Ellis, H.J.C., Hislop, G.W., and Purcell, M. (2013). Project Selection for Student Involvement in Humanitarian FOSS. Workshop at 26th Annual Conference on Software Engineering Education and Training (CSEET). San Francisco.<br />
<br />
* Ellis, H.J.C., Hislop, G.W., Purcell, M., and Postner, L. (2013). Project Selection for Student Participation in Humanitarian FOSS. Workshop at CCSC NE.<br />
<br />
* Ellis, H.J.C., and Hislop, G.W., “Project Selection for Student Participation in Humanitarian FOSS,” 26th Annual Conference on Software Engineering Education and Training, San Francisco, May. 2013<br />
<br />
* Ellis, H.J.C., and Hislop, G.W., “Student Participation in Humanitarian Open Source Software (HFOSS),” Lightening Talk, 2011 International Computing Education Research Workshop, Providence, RI, August, 2011. <br />
<br />
* Morelli, R.A., Danner, N., Iyengar, J., de Lanerolle, T. R., and Ellis, H.J.C., “Teaching and Building Humanitarian Open Source Software,” SIGCSE 2008, Technical Symposium on Computer Science Education, Portland OR, Mar. 2008.<br />
<br />
* Morelli, R.A., Danner, N., Iyengar, J., de Lanerolle, T. R., and Ellis, H.J.C., “Teaching and Building Humanitarian Open Source Software,” SIGCSE 2008, Technical Symposium on Computer Science Education, Portland OR, Mar. 2008.<br />
<br />
<br />
[[Category:Reference]]</div>Cmurphyhttp://www.foss2serve.org/index.php/PublicationsPublications2017-09-25T02:31:02Z<p>Cmurphy: /* Panels and Posters */</p>
<hr />
<div><br />
This page contains references to publications and events that are related to the effort to help students contribute to HFOSS.<br />
<br />
== Papers ==<br />
Journals<br />
* Hislop, Gregory W. and Jackson, Stoney and Ellis, Heidi J.C. (2015). FOSS Artifacts for Evaluating Students on Team Projects. Proceedings of the 16th Annual Conference on Information Technology Education. New York, NY, USA.<br />
<br />
* Hislop, Gregory W. and Ellis, Heidi J.C. (2015). Practical Experiences for IT Students in Humanitarian Free and Open Source Software Projects. Proceedings of the 16th Annual Conference on Information Technology Education. New York, NY, USA.<br />
<br />
* Heidi J. C. Ellis, Gregory W. Hislop, Stoney Jackson, and Lori Postner. 2015. Team Project Experiences in Humanitarian Free and Open Source Software (HFOSS). Trans. Comput. Educ. 15, 4, Article 18 (December 2015), 23 pages. DOI=http://dx.doi.org/10.1145/2684812 <br />
<br />
* Gregory W. Hislop, Heidi J.C. Ellis, S. Monisha Pulimood, Becka Morgan, Suzanne Mello-Stark, Ben Coleman, and Cam Macdonell. 2015. A Multi-Institutional Study of Learning via Student Involvement in Humanitarian Free and Open Source Software Projects. In Proceedings of the eleventh annual International Conference on International Computing Education Research (ICER '15). ACM, New York, NY, USA, 199-206. DOI=http://dx.doi.org/10.1145<br />
<br />
* Ellis, H. J. C., & Hislop, G. W., & Pulimood, S. M., & Morgan, B., & Coleman, B. (2015, June), Software Engineering Learning in HFOSS: A Multi-Institutional Study Paper presented at 2015 ASEE Annual Conference and Exposition, Seattle, Washington. DOI=http://dx.doi.org/10.18260/p.24716<br />
<br />
* Jackson, S., Ellis, H. (2015). Supporting HFOSS using Scrum in a Capstone Course. Abstract and presentation for SIGCAS Symposium on Computing for Social Good. SIGCAS Comput. Soc. 45, 2 (July 2015). <br />
<br />
* Postner, L., Jackson, S., Ellis, H., Hislop, G., Burdge, D., and Goggins, S. (2015). Using Humanitarian Free and Open Source Software (HFOSS) to Introduce Computing for the Social Good. Abstract and presentation for SIGCAS Symposium on Computing for Social Good. SIGCAS Comput. Soc. 45, 2 (July 2015), 3535.<br />
<br />
* Heidi J.C. Ellis, Stoney Jackson, Darci Burdge, Lori Postner, Gregory W. Hislop, and Joanie Diggs. 2014. Learning within a professional environment: shared ownership of an HFOSS project. In Proceedings of the 15th Annual Conference on Information technology education (SIGITE '14). ACM, New York, NY, USA, 95-100. DOI=http://dx.doi.org/10.1145/2656450.2656468 <br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Purcell, M.; Chua, M.; Dziallas, S., "Towards a model of faculty development for FOSS in education," in Software Engineering Education and Training (CSEE&T), 2013 IEEE 26th Conference on , vol., no., pp.269-273, 19-21 May 2013. DOI=http://dx.doi.org/10.1109/CSEET.2013.6595259<br />
<br />
* Ellis, H. J., & Hislop, G. W., & Rodriguez, J. S., & Morelli, R. (2012, June), Student Software Engineering Learning via Participation in Humanitarian FOSS Projects Paper presented at 2012 ASEE Annual Conference, San Antonio, Texas. https://peer.asee.org/21949<br />
<br />
* Heidi J.C. Ellis, Michelle Purcell, and Gregory W. Hislop. 2012. An approach for evaluating FOSS projects for student participation. In Proceedings of the 43rd ACM technical symposium on Computer Science Education (SIGCSE '12). ACM, New York, NY, USA, 415-420. DOI=http://dx.doi.org/10.1145/2157136.2157260<br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Chua, M.; Dziallas, S., "How to involve students in FOSS projects," in Frontiers in Education Conference (FIE), 2011 , vol., no., pp.T1H-1-T1H-6, 12-15 Oct. 2011. DOI=http://dx.doi.org/10.1109/FIE.2011.6142994<br />
<br />
* Ralph Morelli, Allen Tucker, Norman Danner, Trishan R. De Lanerolle, Heidi J. C. Ellis, Ozgur Izmirli, Danny Krizanc, and Gary Parker. 2009. Revitalizing computing education through free and open source software for humanity. Commun. ACM 52, 8 (August 2009), 67-75. DOI=http://doi.acm.org/10.1145/1536616.1536635 <br />
<br />
* Gregory W. Hislop, Heidi J.C. Ellis, and Ralph A. Morelli. 2009. Evaluating student experiences in developing software for humanity. SIGCSE Bull. 41, 3 (July 2009), 263-267. DOI=http://dx.doi.org/10.1145/1595496.1562959 <br />
<br />
* Ellis, H.J.C.; Morelli, R.A.; Hislop, G.W., "Work in progress - challenges to educating students within the Community of Open Source Software for Humanity," in Frontiers in Education Conference, 2008. FIE 2008. 38th Annual , vol., no., pp.S3H-7-S3H-8, 22-25 Oct. 2008. DOI=http://dx.doi.org/10.1109/FIE.2008.4720515<br />
<br />
* Ellis, H.; Morelli, R.A.; Hislop, G.W., "Support for Educating Software Engineers Through Humanitarian Open Source Projects," in Software Engineering Education and Training Workshop, 2008. CSEETW '08. 21st IEEE-CS Conference on , vol., no., pp.1-4, 14-17 April 2008. DOI=http://dx.doi.org/10.1109/CSEETW.2008.5<br />
<br />
* Ellis, H.J.C.; Hislop, G.W., "Fostering the Community of Software Engineering Educators," in Software Engineering Education and Training, 2008. CSEET '08. IEEE 21st Conference on , vol., no., pp.233-237, 14-17 April 2008. DOI=http://dx.doi.org/10.1109/CSEET.2008.18<br />
<br />
* Ellis, H.J.C.; Morelli, R.A.; de Lanerolle, T.R.; Hislop, G.W., "Holistic Software Engineering Education Based on a Humanitarian Open Source Project," in Software Engineering Education & Training, 2007. CSEET '07. 20th Conference on , vol., no., pp.327-335, 3-5 July 2007. DOI=http://dx.doi.org/10.1109/CSEET.2007.26<br />
<br />
* Morelli, R.A., Ellis, H.J.C., de Lanerolle, T., Damon, J., and Walti, C., “Can Student-Written Software Help Sustain Humanitarian FOSS?”, The 4th International Conference on Information Systems for Crisis Response and Management, Delft, the Netherlands, May 2007, pp. 41-44. PDF:http://www.cs.trincoll.edu/~ram/ram/MorelliEtAl_ISCRAM07.pdf<br />
<br />
* Heidi J. C. Ellis, Ralph A. Morelli, Trishan R. de Lanerolle, Jonathan Damon, and Jonathan Raye. 2007. Can humanitarian open-source software development draw new students to CS?. SIGCSE Bull. 39, 1 (March 2007), 551-555. DOI=http://dx.doi.org/10.1145/1227504.1227495<br />
<br />
<br />
Conferences<br />
* Hislop, Gregory W. and Ellis, Heidi J. C. (2016). Building the Student Pipeline to Open Source Communities using HFOSS. 2016 Red Hat Summit.<br />
<br />
* Ellis, Heidi J. C. and Hislop, Gregory W. (2016). Want Students Ready to Contribute? Let’s Discuss What They Should Know!. 2016 OSCON Everything Open Conference.<br />
<br />
== Panels and Posters ==<br />
<br />
* Murphy, Christian and Weng, Judy and Pearce, Jan and Veilleux, Nanette (2017). Addressing Diversity &amp; Inclusion Issues in Computer Science through Contributions to Free and Open Source Software (Birds of a Feather). 2017 ACM Richard Tapia Celebration of Diversity in Computing.<br />
<br />
* Weiss, Stewart and Klukowska, Joanna and Burge, Darci (2017). Injecting Open Source Content Into CS2/Data Structures Courses (poster). 22nd Annual Consortium For Computing Sciences in Colleges, Northeastern Conference. <br />
<br />
* Murphy, Christian and Buffardi, Kevin and Dehlinger, Josh and Lambert, Lynn, and Veilleux, Nanette (2017). Community Engagement with Free and Open Source Software (panel). 48th ACM SIGCSE Technical Symposium on Computer Science Education.<br />
<br />
* Ellis, Heidi J. C. and Hislop, Gregory W. and Burdge, Darci and Postner, Lori and Jackson, Stoney (2016). Learning via Student Participation in Humanitarian Free and Open Source Software Projects. NSF/AAAS conference on Envisioning the Future of Undergraduate STEM Education: Research and Practice.<br />
<br />
* Ellis, Heidi J. C. and Hislop, Gregory W. and Burdge, Darci and Postner, Lori and Jackson, Stoney and Kussmaul, Clif (2016). OpenPath – Improving Student Pathways to Computing Professions via Humanitarian Free and Open Source Software. NSF/AAAS conference on Envisioning the Future of Undergraduate STEM Education: Research and Practice.<br />
<br />
* Jackson, Stoney and Ellis, Heidi J. C. and Hislop, Gregory W. and Postner, Lori and Jackson, Stoney (2015). Team Project Experiences in Humanitarian Free and Open Source Software (HFOSS): Faculty Poster Abstract. J. Comput. Sci. Coll. USA.<br />
<br />
* Alkoby, Karen and Burdge, Darci and Morgan, Becka and Ordonez, Patti and Likins, Gina (2015). Humanitarian Free and Open Source Software: Motivating the Underrepresented. Grace Hopper Celebration of Women in Computing 2015.<br />
<br />
* Pulimood, S. M., Hislop, G.W., and Ellis, H.J.C., “A Multi-Institutional Study of Self-Perceived Learning via Student Involvement in HFOSS Projects,” Poster. CCSC-EA, Atlantic City NJ, Oct. 2015.<br />
<br />
* Gregory W. Hislop and Heidi J.C. Ellis. 2015. Practical Experiences for IT Students in Humanitarian Free and Open Source Software Projects. In Proceedings of the 16th Annual Conference on Information Technology Education (SIGITE '15). ACM, New York, NY, USA, 99-99. DOI=http://dx.doi.org/10.1145/2808006.2808042 <br />
<br />
* Gregory W. Hislop, Stoney Jackson, and Heidi J.C. Ellis. 2015. FOSS Artifacts for Evaluating Students on Team Projects. In Proceedings of the 16th Annual Conference on Information Technology Education (SIGITE '15). ACM, New York, NY, USA, 57-57. DOI=http://dx.doi.org/10.1145/2808006.2808009 <br />
<br />
* Jackson, S., Ellis H.J.C., Hislop, G.W., and Postner, L., “Team project experiences in humanitarian free and open source software (HFOSS)”: faculty poster abstract. J. Comput. Sci. Coll (CCSCNE '15). 30, 6 (June 2015), 156-157.<br />
<br />
* Ellis, H.J.C., Burdge, D., Morgan, R., Ordóñez, P. and Alkoby, K., “Using Humanitarian Free and Open Source Software (HFOSS) to Attract the Underrepresented to Computer Science,” 2015 ACM Richard Tapia Celebration of Diversity in Computing, Boston, MA. Panel.<br />
<br />
* Heidi J.C. Ellis and Gregory W. Hislop. 2014. Structuring software engineering learning within open source software participation. In Proceedings of the 2014 conference on Innovation & technology in computer science education (ITiCSE '14). ACM, New York, NY, USA, 326-326. DOI=http://dx.doi.org/10.1145/2591708.2602681 <br />
<br />
* Heidi J.C. Ellis, Gregory W. Hislop, and Joanmarie Diggs. 2013. Developing HFOSS projects using integrated teams across levels and institutions. In Proceedings of the 18th ACM conference on Innovation and technology in computer science education (ITiCSE '13). ACM, New York, NY, USA, 349-349. DOI=http://dx.doi.org/10.1145/2462476.2465613 <br />
<br />
* Heidi J.C. Ellis, Stoney Jackson, Darci Burdge, Lori Postner, Gregory W. Hislop, and Joanmarie Diggs. 2014. Learning within a professional environment: shared ownership of an HFOSS project. In Proceedings of the 2014 conference on Innovation & technology in computer science education (ITiCSE '14). ACM, New York, NY, USA, 337-337. DOI=http://dx.doi.org/10.1145/2591708.2602660 <br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Purcell, M.; Chua, M.; Dziallas, S., "Towards a model of faculty development for FOSS in education," in Software Engineering Education and Training (CSEE&T), 2013 IEEE 26th Conference on , vol., no., pp.269-273, 19-21 May 2013. DOI=http://dx.doi.org/10.1109/CSEET.2013.6595259<br />
<br />
* Purcell, M., Ellis, H.J.C., and Hislop, G.W. (2013). An Approach for Evaluating Open Source Projects for Student Participation. Poster at CCSC NE.<br />
<br />
* Ellis, H.J.C., and Hislop, G.W. (2013). Community-Based Student Learning via Participation in Humanitarian FOSS Projects. Poster at CCSC NE.<br />
<br />
*Ellis, H.J.C.,, Hislop, G.W., and Morelli, R.A., “SoftHum: Student Participation in the Community of Open Source Software for Humanity,” Poster, 2013 NSF/AASE Conference for Principle Investigators of the Transforming Undergraduate Education STEM program, January 23-25, 2013 Washington, D.C. <br />
<br />
* Ellis, H.J.C.,, Hislop, G.W., and Morelli, R.A., “HumIT: Student IT Services to Support Open Source Software for Humanity,” Poster, 2013 NSF/AASE Conference for Principle Investigators of the Transforming Undergraduate Education STEM program, January 23-25, 2013 Washington, D.C. <br />
<br />
* Clif Kussmaul, Heidi J.C. Ellis, and Gregory W. Hislop. 2012. 50 ways to be a FOSSer: simple ways to involve students & faculty (abstract only). In Proceedings of the 43rd ACM technical symposium on Computer Science Education (SIGCSE '12). ACM, New York, NY, USA, 671-671. DOI=http://dx.doi.org/10.1145/2157136.2157393 <br />
<br />
* Heidi J.C. Ellis and Gregory W. Hislop. 2011. Student IT services to support open source software for humanity. In Proceedings of the 2011 conference on Information technology education (SIGITE '11). ACM, New York, NY, USA, 307-308. DOI=http://dx.doi.org/10.1145/2047594.2047676 <br />
<br />
* Heidi J.C. Ellis, Gregory W. Hislop, and Ralph A. Morelli. 2011. A comparison of software engineering knowledge gained from student participation in humanitarian foss projects. In Proceedings of the 16th annual joint conference on Innovation and technology in computer science education (ITiCSE '11). ACM, New York, NY, USA, 360-360. DOI=http://dx.doi.org/10.1145/1999747.1999874 <br />
<br />
* Heidi J.C. Ellis and Gregory W. Hislop. 2011. Courseware: student learning via FOSS field trips. In Proceedings of the 16th annual joint conference on Innovation and technology in computer science education (ITiCSE '11). ACM, New York, NY, USA, 329-329. DOI=http://dx.doi.org/10.1145/1999747.1999840 <br />
<br />
* Heidi J.C. Ellis, Mel Chua, Matthew C. Jadud, and Gregory W. Hislop. 2011. Learning through open source participation. In Proceedings of the 42nd ACM technical symposium on Computer science education (SIGCSE '11). ACM, New York, NY, USA, 83-84. DOI=http://dx.doi.org/10.1145/1953163.1953191<br />
<br />
* Ellis, H.J.C., Hislop, G.W., and Morelli, R.A., “SoftHum: Student Participation in the Community of Open Source Software for Humanity,” Poster, NSF 2011 CCLI-TUES PIs Conference, Washington, DC, Jan. 26-28, 2011.<br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Chua, M.; Kussmaul, Clif; Burke, Matthew M., "Panel — Teaching students to participate in Open Source Software projects," in Frontiers in Education Conference (FIE), 2010 IEEE , vol., no., pp.F2B-1-F2B-2, 27-30 Oct. 2010. DOI=http://dx.doi.org/10.1109/FIE.2010.5673437<br />
<br />
* Bonhomme-Biais, A., Ellis, H.J.C., Lockwood, J., and Raschid, L., “Open Source for Good” Panel, Grace Hopper Celebration of Women in Computing, Washington, DC, Oct. 2010<br />
<br />
* Hislop, G.W., Ellis, H.J.C., DeKoenigsburg, G., and Jazayeri, D., “Student Participation in OSS Projects,” The 6th International Conference on Open Source Systems, Notre Dame, IN, June, 2010.<br />
<br />
* Heidi J. C. Ellis, Gregory W. Hislop, Ralph Morelli, and Norman Danner. 2010. Instructional aspects of student participation in humanitarian Free and Open Source Software: panel discussion. J. Comput. Sci. Coll. 25, 6 (June 2010), 152-154. <br />
<br />
* Ellis, H.J.C., Hislop, G.W., and Ibanez, L., “Opportunities for Students to Contribute to FOSS Projects,” O’Reilly Open Source Convention (OSCON), Portland, OR, July 19-23, 2010. [[http://cdn.oreillystatic.com/en/assets/1/event/45/Opportunities%20for%20Students%20to%20Contribute%20to%20FOSS%20Projects%20Presentation.odp .ODP]]<br />
<br />
== Related Efforts ==<br />
* Ellis, Heidi J.C. and Jackson, Stoney and Hislop, Gregory W. and Pulimood, S. Monisha and Likins, Gina (2016). Preparing to Teach Humanitarian Open Source (Abstract Only). Proceedings of the 47th ACM Technical Symposium on Computing Science Education. New York, NY, USA. Birds of a Feather Session (BoF) at SIGCSE Symposium.<br />
<br />
* Rebelsky, Sam A. and Morgan, Becka and Pulimood, S. Monisha and Postner, Lori and Hislop, Gregory W. (2015). Incorporating Humanitarian Free and Open Source Software in CS Classrooms. Grace Hopper Celebration of Women in Computing 2015. Birds of a Feather Session (BoF).<br />
<br />
* Postner, L., Jackson, S., Coleman, B., MelloStark, S., Rebelsky, S. (2015). Student Contributions to Humanitarian Free and Open Source Software (HFOSS). Birds of a Feather Session and abstract at SIGCSE 2015 Symposium.<br />
<br />
* Gregory W. Hislop, Heidi J.C. Ellis, Darci Burdge, Sean Goggins, Lori Postner, and Stoney Jackson. 2013. Encouraging faculty & student involvement in humanitarian free and open source software (HFOSS)(abstract only). In Proceeding of the 44th ACM technical symposium on Computer science education (SIGCSE '13). ACM, New York, NY, USA, 751-751. DOI=http://dx.doi.org/10.1145/2445196.2445481 <br />
<br />
* Wurst, K., Postner, L., and Jackson, S. (2014). Teaching Open Source (Software). Birds of a Feather Session (BoF) at SISCSE Symposium.<br />
<br />
== Workshops ==<br />
* Burdge, Darci and Jackson, Stoney (2016). Git 101: Foundations for a Common Workflow to Contribute to HFOSS: Tutorial Presentation. J. Comput. Sci. Coll. 31 (6), 18-20. <br />
<br />
* Burdge, Darci and Jackson, Stoney (2016). Git 102: A Common Workflow to Contribute to HFOSS: Tutorial Presentation. J. Comput. Sci. Coll. 31 (6), 34-36.<br />
<br />
* Ellis, H.J.C., Jackson, S., Hislop, G.W., Postner, L., and Burdge, D. (2014). Getting Started in Open Source - A Tour of a Real Project. Workshop at CCSC NE.<br />
<br />
* Hislop, G.W., Burdge, D., Postner, L., and Ellis H.J.C (2013). Preparing for Student Participation in HFOSS Projects - FOSS Tools and Techniques. Workshop at CCSC E.<br />
<br />
* Ellis, H.J.C., and Hislop, G.W. (2013). Project Selection for Student Participation in Humanitarian FOSS. Workshop at the 26th Annual Conference on Software Engineering Education and Training (SIGITE).<br />
<br />
* Ellis, H.J.C., Hislop, G.W., and Purcell, M. (2013). Project Selection for Student Involvement in Humanitarian FOSS. Workshop at 26th Annual Conference on Software Engineering Education and Training (CSEET). San Francisco.<br />
<br />
* Ellis, H.J.C., Hislop, G.W., Purcell, M., and Postner, L. (2013). Project Selection for Student Participation in Humanitarian FOSS. Workshop at CCSC NE.<br />
<br />
* Ellis, H.J.C., and Hislop, G.W., “Project Selection for Student Participation in Humanitarian FOSS,” 26th Annual Conference on Software Engineering Education and Training, San Francisco, May. 2013<br />
<br />
* Ellis, H.J.C., and Hislop, G.W., “Student Participation in Humanitarian Open Source Software (HFOSS),” Lightening Talk, 2011 International Computing Education Research Workshop, Providence, RI, August, 2011. <br />
<br />
* Morelli, R.A., Danner, N., Iyengar, J., de Lanerolle, T. R., and Ellis, H.J.C., “Teaching and Building Humanitarian Open Source Software,” SIGCSE 2008, Technical Symposium on Computer Science Education, Portland OR, Mar. 2008.<br />
<br />
* Morelli, R.A., Danner, N., Iyengar, J., de Lanerolle, T. R., and Ellis, H.J.C., “Teaching and Building Humanitarian Open Source Software,” SIGCSE 2008, Technical Symposium on Computer Science Education, Portland OR, Mar. 2008.<br />
<br />
<br />
[[Category:Reference]]</div>Cmurphyhttp://www.foss2serve.org/index.php/PublicationsPublications2017-03-09T22:42:52Z<p>Cmurphy: /* Panels and Posters */</p>
<hr />
<div><br />
This page contains references to publications and events that are related to the effort to help students contribute to HFOSS.<br />
<br />
== Papers ==<br />
Journals<br />
* Hislop, Gregory W. and Jackson, Stoney and Ellis, Heidi J.C. (2015). FOSS Artifacts for Evaluating Students on Team Projects. Proceedings of the 16th Annual Conference on Information Technology Education. New York, NY, USA.<br />
<br />
* Hislop, Gregory W. and Ellis, Heidi J.C. (2015). Practical Experiences for IT Students in Humanitarian Free and Open Source Software Projects. Proceedings of the 16th Annual Conference on Information Technology Education. New York, NY, USA.<br />
<br />
* Heidi J. C. Ellis, Gregory W. Hislop, Stoney Jackson, and Lori Postner. 2015. Team Project Experiences in Humanitarian Free and Open Source Software (HFOSS). Trans. Comput. Educ. 15, 4, Article 18 (December 2015), 23 pages. DOI=http://dx.doi.org/10.1145/2684812 <br />
<br />
* Gregory W. Hislop, Heidi J.C. Ellis, S. Monisha Pulimood, Becka Morgan, Suzanne Mello-Stark, Ben Coleman, and Cam Macdonell. 2015. A Multi-Institutional Study of Learning via Student Involvement in Humanitarian Free and Open Source Software Projects. In Proceedings of the eleventh annual International Conference on International Computing Education Research (ICER '15). ACM, New York, NY, USA, 199-206. DOI=http://dx.doi.org/10.1145<br />
<br />
* Ellis, H. J. C., & Hislop, G. W., & Pulimood, S. M., & Morgan, B., & Coleman, B. (2015, June), Software Engineering Learning in HFOSS: A Multi-Institutional Study Paper presented at 2015 ASEE Annual Conference and Exposition, Seattle, Washington. DOI=http://dx.doi.org/10.18260/p.24716<br />
<br />
* Jackson, S., Ellis, H. (2015). Supporting HFOSS using Scrum in a Capstone Course. Abstract and presentation for SIGCAS Symposium on Computing for Social Good. SIGCAS Comput. Soc. 45, 2 (July 2015). <br />
<br />
* Postner, L., Jackson, S., Ellis, H., Hislop, G., Burdge, D., and Goggins, S. (2015). Using Humanitarian Free and Open Source Software (HFOSS) to Introduce Computing for the Social Good. Abstract and presentation for SIGCAS Symposium on Computing for Social Good. SIGCAS Comput. Soc. 45, 2 (July 2015), 3535.<br />
<br />
* Heidi J.C. Ellis, Stoney Jackson, Darci Burdge, Lori Postner, Gregory W. Hislop, and Joanie Diggs. 2014. Learning within a professional environment: shared ownership of an HFOSS project. In Proceedings of the 15th Annual Conference on Information technology education (SIGITE '14). ACM, New York, NY, USA, 95-100. DOI=http://dx.doi.org/10.1145/2656450.2656468 <br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Purcell, M.; Chua, M.; Dziallas, S., "Towards a model of faculty development for FOSS in education," in Software Engineering Education and Training (CSEE&T), 2013 IEEE 26th Conference on , vol., no., pp.269-273, 19-21 May 2013. DOI=http://dx.doi.org/10.1109/CSEET.2013.6595259<br />
<br />
* Ellis, H. J., & Hislop, G. W., & Rodriguez, J. S., & Morelli, R. (2012, June), Student Software Engineering Learning via Participation in Humanitarian FOSS Projects Paper presented at 2012 ASEE Annual Conference, San Antonio, Texas. https://peer.asee.org/21949<br />
<br />
* Heidi J.C. Ellis, Michelle Purcell, and Gregory W. Hislop. 2012. An approach for evaluating FOSS projects for student participation. In Proceedings of the 43rd ACM technical symposium on Computer Science Education (SIGCSE '12). ACM, New York, NY, USA, 415-420. DOI=http://dx.doi.org/10.1145/2157136.2157260<br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Chua, M.; Dziallas, S., "How to involve students in FOSS projects," in Frontiers in Education Conference (FIE), 2011 , vol., no., pp.T1H-1-T1H-6, 12-15 Oct. 2011. DOI=http://dx.doi.org/10.1109/FIE.2011.6142994<br />
<br />
* Ralph Morelli, Allen Tucker, Norman Danner, Trishan R. De Lanerolle, Heidi J. C. Ellis, Ozgur Izmirli, Danny Krizanc, and Gary Parker. 2009. Revitalizing computing education through free and open source software for humanity. Commun. ACM 52, 8 (August 2009), 67-75. DOI=http://doi.acm.org/10.1145/1536616.1536635 <br />
<br />
* Gregory W. Hislop, Heidi J.C. Ellis, and Ralph A. Morelli. 2009. Evaluating student experiences in developing software for humanity. SIGCSE Bull. 41, 3 (July 2009), 263-267. DOI=http://dx.doi.org/10.1145/1595496.1562959 <br />
<br />
* Ellis, H.J.C.; Morelli, R.A.; Hislop, G.W., "Work in progress - challenges to educating students within the Community of Open Source Software for Humanity," in Frontiers in Education Conference, 2008. FIE 2008. 38th Annual , vol., no., pp.S3H-7-S3H-8, 22-25 Oct. 2008. DOI=http://dx.doi.org/10.1109/FIE.2008.4720515<br />
<br />
* Ellis, H.; Morelli, R.A.; Hislop, G.W., "Support for Educating Software Engineers Through Humanitarian Open Source Projects," in Software Engineering Education and Training Workshop, 2008. CSEETW '08. 21st IEEE-CS Conference on , vol., no., pp.1-4, 14-17 April 2008. DOI=http://dx.doi.org/10.1109/CSEETW.2008.5<br />
<br />
* Ellis, H.J.C.; Hislop, G.W., "Fostering the Community of Software Engineering Educators," in Software Engineering Education and Training, 2008. CSEET '08. IEEE 21st Conference on , vol., no., pp.233-237, 14-17 April 2008. DOI=http://dx.doi.org/10.1109/CSEET.2008.18<br />
<br />
* Ellis, H.J.C.; Morelli, R.A.; de Lanerolle, T.R.; Hislop, G.W., "Holistic Software Engineering Education Based on a Humanitarian Open Source Project," in Software Engineering Education & Training, 2007. CSEET '07. 20th Conference on , vol., no., pp.327-335, 3-5 July 2007. DOI=http://dx.doi.org/10.1109/CSEET.2007.26<br />
<br />
* Morelli, R.A., Ellis, H.J.C., de Lanerolle, T., Damon, J., and Walti, C., “Can Student-Written Software Help Sustain Humanitarian FOSS?”, The 4th International Conference on Information Systems for Crisis Response and Management, Delft, the Netherlands, May 2007, pp. 41-44. PDF:http://www.cs.trincoll.edu/~ram/ram/MorelliEtAl_ISCRAM07.pdf<br />
<br />
* Heidi J. C. Ellis, Ralph A. Morelli, Trishan R. de Lanerolle, Jonathan Damon, and Jonathan Raye. 2007. Can humanitarian open-source software development draw new students to CS?. SIGCSE Bull. 39, 1 (March 2007), 551-555. DOI=http://dx.doi.org/10.1145/1227504.1227495<br />
<br />
<br />
Conferences<br />
* Hislop, Gregory W. and Ellis, Heidi J. C. (2016). Building the Student Pipeline to Open Source Communities using HFOSS. 2016 Red Hat Summit.<br />
<br />
* Ellis, Heidi J. C. and Hislop, Gregory W. (2016). Want Students Ready to Contribute? Let’s Discuss What They Should Know!. 2016 OSCON Everything Open Conference.<br />
<br />
== Panels and Posters ==<br />
* Murphy, Christian and Buffardi, Kevin and Dehlinger, Josh and Lambert, Lynn, and Veilleux, Nanette (2017). Community Engagement with Free and Open Source Software (panel). 48th ACM SIGCSE Technical Symposium on Computer Science Education.<br />
<br />
* Ellis, Heidi J. C. and Hislop, Gregory W. and Burdge, Darci and Postner, Lori and Jackson, Stoney (2016). Learning via Student Participation in Humanitarian Free and Open Source Software Projects. NSF/AAAS conference on Envisioning the Future of Undergraduate STEM Education: Research and Practice.<br />
<br />
* Ellis, Heidi J. C. and Hislop, Gregory W. and Burdge, Darci and Postner, Lori and Jackson, Stoney and Kussmaul, Clif (2016). OpenPath – Improving Student Pathways to Computing Professions via Humanitarian Free and Open Source Software. NSF/AAAS conference on Envisioning the Future of Undergraduate STEM Education: Research and Practice.<br />
<br />
* Jackson, Stoney and Ellis, Heidi J. C. and Hislop, Gregory W. and Postner, Lori and Jackson, Stoney (2015). Team Project Experiences in Humanitarian Free and Open Source Software (HFOSS): Faculty Poster Abstract. J. Comput. Sci. Coll. USA.<br />
<br />
* Alkoby, Karen and Burdge, Darci and Morgan, Becka and Ordonez, Patti and Likins, Gina (2015). Humanitarian Free and Open Source Software: Motivating the Underrepresented. Grace Hopper Celebration of Women in Computing 2015.<br />
<br />
* Pulimood, S. M., Hislop, G.W., and Ellis, H.J.C., “A Multi-Institutional Study of Self-Perceived Learning via Student Involvement in HFOSS Projects,” Poster. CCSC-EA, Atlantic City NJ, Oct. 2015.<br />
<br />
* Gregory W. Hislop and Heidi J.C. Ellis. 2015. Practical Experiences for IT Students in Humanitarian Free and Open Source Software Projects. In Proceedings of the 16th Annual Conference on Information Technology Education (SIGITE '15). ACM, New York, NY, USA, 99-99. DOI=http://dx.doi.org/10.1145/2808006.2808042 <br />
<br />
* Gregory W. Hislop, Stoney Jackson, and Heidi J.C. Ellis. 2015. FOSS Artifacts for Evaluating Students on Team Projects. In Proceedings of the 16th Annual Conference on Information Technology Education (SIGITE '15). ACM, New York, NY, USA, 57-57. DOI=http://dx.doi.org/10.1145/2808006.2808009 <br />
<br />
* Jackson, S., Ellis H.J.C., Hislop, G.W., and Postner, L., “Team project experiences in humanitarian free and open source software (HFOSS)”: faculty poster abstract. J. Comput. Sci. Coll (CCSCNE '15). 30, 6 (June 2015), 156-157.<br />
<br />
* Ellis, H.J.C., Burdge, D., Morgan, R., Ordóñez, P. and Alkoby, K., “Using Humanitarian Free and Open Source Software (HFOSS) to Attract the Underrepresented to Computer Science,” 2015 ACM Richard Tapia Celebration of Diversity in Computing, Boston, MA. Panel.<br />
<br />
* Heidi J.C. Ellis and Gregory W. Hislop. 2014. Structuring software engineering learning within open source software participation. In Proceedings of the 2014 conference on Innovation & technology in computer science education (ITiCSE '14). ACM, New York, NY, USA, 326-326. DOI=http://dx.doi.org/10.1145/2591708.2602681 <br />
<br />
* Heidi J.C. Ellis, Gregory W. Hislop, and Joanmarie Diggs. 2013. Developing HFOSS projects using integrated teams across levels and institutions. In Proceedings of the 18th ACM conference on Innovation and technology in computer science education (ITiCSE '13). ACM, New York, NY, USA, 349-349. DOI=http://dx.doi.org/10.1145/2462476.2465613 <br />
<br />
* Heidi J.C. Ellis, Stoney Jackson, Darci Burdge, Lori Postner, Gregory W. Hislop, and Joanmarie Diggs. 2014. Learning within a professional environment: shared ownership of an HFOSS project. In Proceedings of the 2014 conference on Innovation & technology in computer science education (ITiCSE '14). ACM, New York, NY, USA, 337-337. DOI=http://dx.doi.org/10.1145/2591708.2602660 <br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Purcell, M.; Chua, M.; Dziallas, S., "Towards a model of faculty development for FOSS in education," in Software Engineering Education and Training (CSEE&T), 2013 IEEE 26th Conference on , vol., no., pp.269-273, 19-21 May 2013. DOI=http://dx.doi.org/10.1109/CSEET.2013.6595259<br />
<br />
* Purcell, M., Ellis, H.J.C., and Hislop, G.W. (2013). An Approach for Evaluating Open Source Projects for Student Participation. Poster at CCSC NE.<br />
<br />
* Ellis, H.J.C., and Hislop, G.W. (2013). Community-Based Student Learning via Participation in Humanitarian FOSS Projects. Poster at CCSC NE.<br />
<br />
*Ellis, H.J.C.,, Hislop, G.W., and Morelli, R.A., “SoftHum: Student Participation in the Community of Open Source Software for Humanity,” Poster, 2013 NSF/AASE Conference for Principle Investigators of the Transforming Undergraduate Education STEM program, January 23-25, 2013 Washington, D.C. <br />
<br />
* Ellis, H.J.C.,, Hislop, G.W., and Morelli, R.A., “HumIT: Student IT Services to Support Open Source Software for Humanity,” Poster, 2013 NSF/AASE Conference for Principle Investigators of the Transforming Undergraduate Education STEM program, January 23-25, 2013 Washington, D.C. <br />
<br />
* Clif Kussmaul, Heidi J.C. Ellis, and Gregory W. Hislop. 2012. 50 ways to be a FOSSer: simple ways to involve students & faculty (abstract only). In Proceedings of the 43rd ACM technical symposium on Computer Science Education (SIGCSE '12). ACM, New York, NY, USA, 671-671. DOI=http://dx.doi.org/10.1145/2157136.2157393 <br />
<br />
* Heidi J.C. Ellis and Gregory W. Hislop. 2011. Student IT services to support open source software for humanity. In Proceedings of the 2011 conference on Information technology education (SIGITE '11). ACM, New York, NY, USA, 307-308. DOI=http://dx.doi.org/10.1145/2047594.2047676 <br />
<br />
* Heidi J.C. Ellis, Gregory W. Hislop, and Ralph A. Morelli. 2011. A comparison of software engineering knowledge gained from student participation in humanitarian foss projects. In Proceedings of the 16th annual joint conference on Innovation and technology in computer science education (ITiCSE '11). ACM, New York, NY, USA, 360-360. DOI=http://dx.doi.org/10.1145/1999747.1999874 <br />
<br />
* Heidi J.C. Ellis and Gregory W. Hislop. 2011. Courseware: student learning via FOSS field trips. In Proceedings of the 16th annual joint conference on Innovation and technology in computer science education (ITiCSE '11). ACM, New York, NY, USA, 329-329. DOI=http://dx.doi.org/10.1145/1999747.1999840 <br />
<br />
* Heidi J.C. Ellis, Mel Chua, Matthew C. Jadud, and Gregory W. Hislop. 2011. Learning through open source participation. In Proceedings of the 42nd ACM technical symposium on Computer science education (SIGCSE '11). ACM, New York, NY, USA, 83-84. DOI=http://dx.doi.org/10.1145/1953163.1953191<br />
<br />
* Ellis, H.J.C., Hislop, G.W., and Morelli, R.A., “SoftHum: Student Participation in the Community of Open Source Software for Humanity,” Poster, NSF 2011 CCLI-TUES PIs Conference, Washington, DC, Jan. 26-28, 2011.<br />
<br />
* Ellis, H.J.C.; Hislop, G.W.; Chua, M.; Kussmaul, Clif; Burke, Matthew M., "Panel — Teaching students to participate in Open Source Software projects," in Frontiers in Education Conference (FIE), 2010 IEEE , vol., no., pp.F2B-1-F2B-2, 27-30 Oct. 2010. DOI=http://dx.doi.org/10.1109/FIE.2010.5673437<br />
<br />
* Bonhomme-Biais, A., Ellis, H.J.C., Lockwood, J., and Raschid, L., “Open Source for Good” Panel, Grace Hopper Celebration of Women in Computing, Washington, DC, Oct. 2010<br />
<br />
* Hislop, G.W., Ellis, H.J.C., DeKoenigsburg, G., and Jazayeri, D., “Student Participation in OSS Projects,” The 6th International Conference on Open Source Systems, Notre Dame, IN, June, 2010.<br />
<br />
* Heidi J. C. Ellis, Gregory W. Hislop, Ralph Morelli, and Norman Danner. 2010. Instructional aspects of student participation in humanitarian Free and Open Source Software: panel discussion. J. Comput. Sci. Coll. 25, 6 (June 2010), 152-154. <br />
<br />
* Ellis, H.J.C., Hislop, G.W., and Ibanez, L., “Opportunities for Students to Contribute to FOSS Projects,” O’Reilly Open Source Convention (OSCON), Portland, OR, July 19-23, 2010. [[http://cdn.oreillystatic.com/en/assets/1/event/45/Opportunities%20for%20Students%20to%20Contribute%20to%20FOSS%20Projects%20Presentation.odp .ODP]]<br />
<br />
== Related Efforts ==<br />
* Ellis, Heidi J.C. and Jackson, Stoney and Hislop, Gregory W. and Pulimood, S. Monisha and Likins, Gina (2016). Preparing to Teach Humanitarian Open Source (Abstract Only). Proceedings of the 47th ACM Technical Symposium on Computing Science Education. New York, NY, USA. Birds of a Feather Session (BoF) at SIGCSE Symposium.<br />
<br />
* Rebelsky, Sam A. and Morgan, Becka and Pulimood, S. Monisha and Postner, Lori and Hislop, Gregory W. (2015). Incorporating Humanitarian Free and Open Source Software in CS Classrooms. Grace Hopper Celebration of Women in Computing 2015. Birds of a Feather Session (BoF).<br />
<br />
* Postner, L., Jackson, S., Coleman, B., MelloStark, S., Rebelsky, S. (2015). Student Contributions to Humanitarian Free and Open Source Software (HFOSS). Birds of a Feather Session and abstract at SIGCSE 2015 Symposium.<br />
<br />
* Gregory W. Hislop, Heidi J.C. Ellis, Darci Burdge, Sean Goggins, Lori Postner, and Stoney Jackson. 2013. Encouraging faculty & student involvement in humanitarian free and open source software (HFOSS)(abstract only). In Proceeding of the 44th ACM technical symposium on Computer science education (SIGCSE '13). ACM, New York, NY, USA, 751-751. DOI=http://dx.doi.org/10.1145/2445196.2445481 <br />
<br />
* Wurst, K., Postner, L., and Jackson, S. (2014). Teaching Open Source (Software). Birds of a Feather Session (BoF) at SISCSE Symposium.<br />
<br />
== Workshops ==<br />
* Burdge, Darci and Jackson, Stoney (2016). Git 101: Foundations for a Common Workflow to Contribute to HFOSS: Tutorial Presentation. J. Comput. Sci. Coll. 31 (6), 18-20. <br />
<br />
* Burdge, Darci and Jackson, Stoney (2016). Git 102: A Common Workflow to Contribute to HFOSS: Tutorial Presentation. J. Comput. Sci. Coll. 31 (6), 34-36.<br />
<br />
* Ellis, H.J.C., Jackson, S., Hislop, G.W., Postner, L., and Burdge, D. (2014). Getting Started in Open Source - A Tour of a Real Project. Workshop at CCSC NE.<br />
<br />
* Hislop, G.W., Burdge, D., Postner, L., and Ellis H.J.C (2013). Preparing for Student Participation in HFOSS Projects - FOSS Tools and Techniques. Workshop at CCSC E.<br />
<br />
* Ellis, H.J.C., and Hislop, G.W. (2013). Project Selection for Student Participation in Humanitarian FOSS. Workshop at the 26th Annual Conference on Software Engineering Education and Training (SIGITE).<br />
<br />
* Ellis, H.J.C., Hislop, G.W., and Purcell, M. (2013). Project Selection for Student Involvement in Humanitarian FOSS. Workshop at 26th Annual Conference on Software Engineering Education and Training (CSEET). San Francisco.<br />
<br />
* Ellis, H.J.C., Hislop, G.W., Purcell, M., and Postner, L. (2013). Project Selection for Student Participation in Humanitarian FOSS. Workshop at CCSC NE.<br />
<br />
* Ellis, H.J.C., and Hislop, G.W., “Project Selection for Student Participation in Humanitarian FOSS,” 26th Annual Conference on Software Engineering Education and Training, San Francisco, May. 2013<br />
<br />
* Ellis, H.J.C., and Hislop, G.W., “Student Participation in Humanitarian Open Source Software (HFOSS),” Lightening Talk, 2011 International Computing Education Research Workshop, Providence, RI, August, 2011. <br />
<br />
* Morelli, R.A., Danner, N., Iyengar, J., de Lanerolle, T. R., and Ellis, H.J.C., “Teaching and Building Humanitarian Open Source Software,” SIGCSE 2008, Technical Symposium on Computer Science Education, Portland OR, Mar. 2008.<br />
<br />
* Morelli, R.A., Danner, N., Iyengar, J., de Lanerolle, T. R., and Ellis, H.J.C., “Teaching and Building Humanitarian Open Source Software,” SIGCSE 2008, Technical Symposium on Computer Science Education, Portland OR, Mar. 2008.<br />
<br />
<br />
[[Category:Reference]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Propose_a_New_FeaturePropose a New Feature2017-03-09T00:47:19Z<p>Cmurphy: /* Directions */</p>
<hr />
<div>__NOTOC__<br />
=== Overview ===<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
''Propose a New Feature''<br />
|overview= <br />
In this activity, students will analyze a project to identify a new feature to implement. They will document and propose this new feature to the community. To do so, they will need to learn and follow the coding and communication practices of the project community.<br />
|prerequisites=<br />
''What topics and tools does the student need to know prior to beginning this activity?''<br />
|objectives=<br />
''What should the student be able to do after completing this activity?''<br />
|process skills=<br />
''What process skills will the student practice while completing this activity?''<br />
}}<br />
<br />
=== Background ===<br />
<br />
* Is there background reading material?<br />
* What is the rationale for this activity?<br />
<br />
=== Directions ===<br />
<br />
* Identify a new feature to be implemented<br />
* Document the feature<br />
* Propose the feature<br />
<br />
All of this will likely depend on the community's guidelines for proposing features.<br />
<br />
=== Deliverables ===<br />
<br />
* What will the student hand in?<br />
<br />
= Notes for Instructors =<br />
The remaining sections of this document are intended for the instructor. They are not part of the learning activity that would be given to students.<br />
<br />
=== Assessment ===<br />
<br />
* How will the activity be graded?<br />
* How will learning will be measured? Ideally, there should be a way to measure each of the objectives described above. <br />
* How will feedback to the student be determined? <br />
<br />
Include sample assessment questions/rubrics. Feel free to indicate that the activity itself is not graded, however it would be helpful to include any questions that might be used at a later date to interpret learning, for example on a quiz or exam. <br />
<br />
The form of the assessment is expected to vary by assignment. One possible format is the table:<br />
{| class="wikitable"<br />
! Criteria<br />
! Level 1 (fail)<br />
! Level 2 (pass)<br />
! Level 3 (good)<br />
! Level 4 (exceptional)<br />
|-<br />
| '''Criterion 1...'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Criterion 2...'''<br />
| <br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* What should the instructor know before using this activity?<br />
* What are some likely difficulties that an instructor may encounter using this activity?<br />
<br />
=== Suggestions for Open Source Community ===<br />
<br />
Suggestions for an open source community member who is working in conjunction with the instructor.<br />
<br />
=== Additional Information ===<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
''What [[ACM Body of Knowledge]] Area and Unit(s) are covered?''<br />
|acm topic=<br />
''What specific topics are addressed? The Computing Curricula 2013 provides a list of topics in Appendix A - The Body of Knowledge (page 58) - https://www.acm.org/education/CS2013-final-report.pdf''<br />
|difficulty=<br />
''Is this activity easy, medium, or hard?''<br />
|time=<br />
''How long should a typical student take to complete the activity?''<br />
|environment=<br />
''What does the student need? (e.g. Internet access, IRC client, Git Hub account, LINUX machine, etc.)''<br />
|author=<br />
''Who wrote this activity?''<br />
|source=<br />
''Is there another activity on which this activity is based? If so, please provide a link to the original resource.''<br />
|license=<br />
''Under which license is this material made available? We request that you pick a [http://creativecommons.org/licenses/ Creative Commons license].''<br />
''We suggest using a template like'': <nowiki>{{License CC BY}}</nowiki> or <nowiki>{{License CC BY SA}}</nowiki><br />
}}<br />
<br />
--------------------<br />
<!-- this license is for the FORMAT - remove it for a new activity --><br />
For this blank '''format''': {{License CC BY SA}}<br />
<br />
[[Category:Learning Activity]]<br />
<!-- add appropriate subcategory(s) for a new activity <br />
[[Category:LEARNING_ACTIVITY_SUBCATEGORY]] --><br />
<br />
<!-- this category is for the FORMAT - remove it for a new activity <br />
[[Category:Formats]] --><br />
[[Category:Minimal Sketch]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Talk:Propose_a_New_FeatureTalk:Propose a New Feature2017-03-09T00:46:13Z<p>Cmurphy: Created page with "There are some rough ideas for what could go in this Learning Activity here and [[:Possible_Pathways_an..."</p>
<hr />
<div>There are some rough ideas for what could go in this Learning Activity [[:Possible_Pathways_and_Learning_Activities#Specification_.26_Coding|here]] and [[:Possible_Pathways_and_Learning_Activities#Specification_and_Design|here]].</div>Cmurphyhttp://www.foss2serve.org/index.php/Propose_a_New_FeaturePropose a New Feature2017-03-09T00:45:11Z<p>Cmurphy: /* Background */</p>
<hr />
<div>__NOTOC__<br />
=== Overview ===<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
''Propose a New Feature''<br />
|overview= <br />
In this activity, students will analyze the project to identify new features. They will document and propose this new feature to the community.<br />
|prerequisites=<br />
''What topics and tools does the student need to know prior to beginning this activity?''<br />
|objectives=<br />
''What should the student be able to do after completing this activity?''<br />
|process skills=<br />
''What process skills will the student practice while completing this activity?''<br />
}}<br />
<br />
=== Background ===<br />
<br />
* Is there background reading material?<br />
* What is the rationale for this activity?<br />
<br />
=== Directions ===<br />
<br />
* What should the student do?<br />
<br />
=== Deliverables ===<br />
<br />
* What will the student hand in?<br />
<br />
= Notes for Instructors =<br />
The remaining sections of this document are intended for the instructor. They are not part of the learning activity that would be given to students.<br />
<br />
=== Assessment ===<br />
<br />
* How will the activity be graded?<br />
* How will learning will be measured? Ideally, there should be a way to measure each of the objectives described above. <br />
* How will feedback to the student be determined? <br />
<br />
Include sample assessment questions/rubrics. Feel free to indicate that the activity itself is not graded, however it would be helpful to include any questions that might be used at a later date to interpret learning, for example on a quiz or exam. <br />
<br />
The form of the assessment is expected to vary by assignment. One possible format is the table:<br />
{| class="wikitable"<br />
! Criteria<br />
! Level 1 (fail)<br />
! Level 2 (pass)<br />
! Level 3 (good)<br />
! Level 4 (exceptional)<br />
|-<br />
| '''Criterion 1...'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Criterion 2...'''<br />
| <br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* What should the instructor know before using this activity?<br />
* What are some likely difficulties that an instructor may encounter using this activity?<br />
<br />
=== Suggestions for Open Source Community ===<br />
<br />
Suggestions for an open source community member who is working in conjunction with the instructor.<br />
<br />
=== Additional Information ===<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
''What [[ACM Body of Knowledge]] Area and Unit(s) are covered?''<br />
|acm topic=<br />
''What specific topics are addressed? The Computing Curricula 2013 provides a list of topics in Appendix A - The Body of Knowledge (page 58) - https://www.acm.org/education/CS2013-final-report.pdf''<br />
|difficulty=<br />
''Is this activity easy, medium, or hard?''<br />
|time=<br />
''How long should a typical student take to complete the activity?''<br />
|environment=<br />
''What does the student need? (e.g. Internet access, IRC client, Git Hub account, LINUX machine, etc.)''<br />
|author=<br />
''Who wrote this activity?''<br />
|source=<br />
''Is there another activity on which this activity is based? If so, please provide a link to the original resource.''<br />
|license=<br />
''Under which license is this material made available? We request that you pick a [http://creativecommons.org/licenses/ Creative Commons license].''<br />
''We suggest using a template like'': <nowiki>{{License CC BY}}</nowiki> or <nowiki>{{License CC BY SA}}</nowiki><br />
}}<br />
<br />
--------------------<br />
<!-- this license is for the FORMAT - remove it for a new activity --><br />
For this blank '''format''': {{License CC BY SA}}<br />
<br />
[[Category:Learning Activity]]<br />
<!-- add appropriate subcategory(s) for a new activity <br />
[[Category:LEARNING_ACTIVITY_SUBCATEGORY]] --><br />
<br />
<!-- this category is for the FORMAT - remove it for a new activity <br />
[[Category:Formats]] --><br />
[[Category:Minimal Sketch]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Propose_a_New_FeaturePropose a New Feature2017-03-09T00:43:34Z<p>Cmurphy: /* Background */</p>
<hr />
<div>__NOTOC__<br />
=== Overview ===<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
''Propose a New Feature''<br />
|overview= <br />
In this activity, students will analyze the project to identify new features. They will document and propose this new feature to the community.<br />
|prerequisites=<br />
''What topics and tools does the student need to know prior to beginning this activity?''<br />
|objectives=<br />
''What should the student be able to do after completing this activity?''<br />
|process skills=<br />
''What process skills will the student practice while completing this activity?''<br />
}}<br />
<br />
=== Background ===<br />
<br />
* Is there background reading material?<br />
* What is the rationale for this activity?<br />
<br />
[[:Possible_Pathways_and_Learning_Activities#Specification_.26_Coding|look here!]]<br />
<br />
=== Directions ===<br />
<br />
* What should the student do?<br />
<br />
=== Deliverables ===<br />
<br />
* What will the student hand in?<br />
<br />
= Notes for Instructors =<br />
The remaining sections of this document are intended for the instructor. They are not part of the learning activity that would be given to students.<br />
<br />
=== Assessment ===<br />
<br />
* How will the activity be graded?<br />
* How will learning will be measured? Ideally, there should be a way to measure each of the objectives described above. <br />
* How will feedback to the student be determined? <br />
<br />
Include sample assessment questions/rubrics. Feel free to indicate that the activity itself is not graded, however it would be helpful to include any questions that might be used at a later date to interpret learning, for example on a quiz or exam. <br />
<br />
The form of the assessment is expected to vary by assignment. One possible format is the table:<br />
{| class="wikitable"<br />
! Criteria<br />
! Level 1 (fail)<br />
! Level 2 (pass)<br />
! Level 3 (good)<br />
! Level 4 (exceptional)<br />
|-<br />
| '''Criterion 1...'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Criterion 2...'''<br />
| <br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* What should the instructor know before using this activity?<br />
* What are some likely difficulties that an instructor may encounter using this activity?<br />
<br />
=== Suggestions for Open Source Community ===<br />
<br />
Suggestions for an open source community member who is working in conjunction with the instructor.<br />
<br />
=== Additional Information ===<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
''What [[ACM Body of Knowledge]] Area and Unit(s) are covered?''<br />
|acm topic=<br />
''What specific topics are addressed? The Computing Curricula 2013 provides a list of topics in Appendix A - The Body of Knowledge (page 58) - https://www.acm.org/education/CS2013-final-report.pdf''<br />
|difficulty=<br />
''Is this activity easy, medium, or hard?''<br />
|time=<br />
''How long should a typical student take to complete the activity?''<br />
|environment=<br />
''What does the student need? (e.g. Internet access, IRC client, Git Hub account, LINUX machine, etc.)''<br />
|author=<br />
''Who wrote this activity?''<br />
|source=<br />
''Is there another activity on which this activity is based? If so, please provide a link to the original resource.''<br />
|license=<br />
''Under which license is this material made available? We request that you pick a [http://creativecommons.org/licenses/ Creative Commons license].''<br />
''We suggest using a template like'': <nowiki>{{License CC BY}}</nowiki> or <nowiki>{{License CC BY SA}}</nowiki><br />
}}<br />
<br />
--------------------<br />
<!-- this license is for the FORMAT - remove it for a new activity --><br />
For this blank '''format''': {{License CC BY SA}}<br />
<br />
[[Category:Learning Activity]]<br />
<!-- add appropriate subcategory(s) for a new activity <br />
[[Category:LEARNING_ACTIVITY_SUBCATEGORY]] --><br />
<br />
<!-- this category is for the FORMAT - remove it for a new activity <br />
[[Category:Formats]] --><br />
[[Category:Minimal Sketch]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Propose_a_New_FeaturePropose a New Feature2017-03-09T00:40:42Z<p>Cmurphy: /* Overview */</p>
<hr />
<div>__NOTOC__<br />
=== Overview ===<br />
<br />
{{Learning Activity Overview<br />
|title=<br />
''Propose a New Feature''<br />
|overview= <br />
''High level description of what the student will do.''<br />
|prerequisites=<br />
''What topics and tools does the student need to know prior to beginning this activity?''<br />
|objectives=<br />
''What should the student be able to do after completing this activity?''<br />
|process skills=<br />
''What process skills will the student practice while completing this activity?''<br />
}}<br />
<br />
=== Background ===<br />
<br />
* Is there background reading material?<br />
* What is the rationale for this activity?<br />
<br />
=== Directions ===<br />
<br />
* What should the student do?<br />
<br />
=== Deliverables ===<br />
<br />
* What will the student hand in?<br />
<br />
= Notes for Instructors =<br />
The remaining sections of this document are intended for the instructor. They are not part of the learning activity that would be given to students.<br />
<br />
=== Assessment ===<br />
<br />
* How will the activity be graded?<br />
* How will learning will be measured? Ideally, there should be a way to measure each of the objectives described above. <br />
* How will feedback to the student be determined? <br />
<br />
Include sample assessment questions/rubrics. Feel free to indicate that the activity itself is not graded, however it would be helpful to include any questions that might be used at a later date to interpret learning, for example on a quiz or exam. <br />
<br />
The form of the assessment is expected to vary by assignment. One possible format is the table:<br />
{| class="wikitable"<br />
! Criteria<br />
! Level 1 (fail)<br />
! Level 2 (pass)<br />
! Level 3 (good)<br />
! Level 4 (exceptional)<br />
|-<br />
| '''Criterion 1...'''<br />
| <br />
| <br />
|<br />
|<br />
<br />
|-<br />
| '''Criterion 2...'''<br />
| <br />
| <br />
| <br />
| <br />
<br />
|}<br />
<br />
=== Comments ===<br />
<br />
* What should the instructor know before using this activity?<br />
* What are some likely difficulties that an instructor may encounter using this activity?<br />
<br />
=== Suggestions for Open Source Community ===<br />
<br />
Suggestions for an open source community member who is working in conjunction with the instructor.<br />
<br />
=== Additional Information ===<br />
<br />
{{Learning Activity Info<br />
|acm unit=<br />
''What [[ACM Body of Knowledge]] Area and Unit(s) are covered?''<br />
|acm topic=<br />
''What specific topics are addressed? The Computing Curricula 2013 provides a list of topics in Appendix A - The Body of Knowledge (page 58) - https://www.acm.org/education/CS2013-final-report.pdf''<br />
|difficulty=<br />
''Is this activity easy, medium, or hard?''<br />
|time=<br />
''How long should a typical student take to complete the activity?''<br />
|environment=<br />
''What does the student need? (e.g. Internet access, IRC client, Git Hub account, LINUX machine, etc.)''<br />
|author=<br />
''Who wrote this activity?''<br />
|source=<br />
''Is there another activity on which this activity is based? If so, please provide a link to the original resource.''<br />
|license=<br />
''Under which license is this material made available? We request that you pick a [http://creativecommons.org/licenses/ Creative Commons license].''<br />
''We suggest using a template like'': <nowiki>{{License CC BY}}</nowiki> or <nowiki>{{License CC BY SA}}</nowiki><br />
}}<br />
<br />
--------------------<br />
<!-- this license is for the FORMAT - remove it for a new activity --><br />
For this blank '''format''': {{License CC BY SA}}<br />
<br />
[[Category:Learning Activity]]<br />
<!-- add appropriate subcategory(s) for a new activity --><br />
[[Category:LEARNING_ACTIVITY_SUBCATEGORY]]<br />
<br />
<!-- this category is for the FORMAT - remove it for a new activity --><br />
[[Category:Formats]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Category_talk:Add_a_Feature_(Pathway)Category talk:Add a Feature (Pathway)2017-03-09T00:39:05Z<p>Cmurphy: </p>
<hr />
<div><br />
There may be some differences in Steps 4 and 5 depending on the community and the tools, e.g. the student may not be able to close the ticket.<br />
<br />
There needs to be a pathway to incorporate the "Tools" and "Community" aspects of the pre-requisites. For instance a potential [[:Possible_Pathways_and_Learning_Activities#Specification_.26_Coding|Specification and Coding]] pathway could be the prerequisite for "Tools" and [[:Possible_Pathways_and_Learning_Activities#Communication_.26_Tools|Communication and Tools]] could be the prerequisite for "Community".</div>Cmurphyhttp://www.foss2serve.org/index.php/Category_talk:Add_a_Feature_(Pathway)Category talk:Add a Feature (Pathway)2017-03-09T00:17:11Z<p>Cmurphy: </p>
<hr />
<div>Need to have an "Identify a Feature to be Added" activity based on assessing the current feature set (for Step 1)<br />
<br />
There may be some differences in Steps 4 and 5 depending on the community and the tools, e.g. the student may not be able to close the ticket.<br />
<br />
There needs to be a pathway to incorporate the "Tools" and "Community" aspects of the pre-requisites. For instance a potential [[:Possible_Pathways_and_Learning_Activities#Specification_.26_Coding|Specification and Coding]] pathway could be the prerequisite for "Tools" and [[:Possible_Pathways_and_Learning_Activities#Communication_.26_Tools|Communication and Tools]] could be the prerequisite for "Community".</div>Cmurphyhttp://www.foss2serve.org/index.php/Category_talk:PathwaysCategory talk:Pathways2017-03-09T00:09:57Z<p>Cmurphy: </p>
<hr />
<div>There should probably be Pathway(s) for becoming proficient in using tools and in communicating with community, perhaps composed of POSSE Stage 1 activities, e.g. FOSS Field Trip.</div>Cmurphyhttp://www.foss2serve.org/index.php/Category_talk:PathwaysCategory talk:Pathways2017-03-09T00:09:25Z<p>Cmurphy: Created page with "There should probably be Pathway(s) for becoming proficient in using tools and in communicating with community, perhaps composed of POSSE Stage A activities, e.g. FOSS Field T..."</p>
<hr />
<div>There should probably be Pathway(s) for becoming proficient in using tools and in communicating with community, perhaps composed of POSSE Stage A activities, e.g. FOSS Field Trip.</div>Cmurphyhttp://www.foss2serve.org/index.php/Category:Add_a_Feature_(Pathway)Category:Add a Feature (Pathway)2017-03-09T00:02:33Z<p>Cmurphy: /* Prerequisites */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''The contributor will''': contribute code to implement a requested feature.<br />
'''The contribution is''': code accepted into the project's codebase to implement a requested feature.<br />
<br />
=== Prerequisites ===<br />
<br />
{| {{Pathway Prerequisite Table}}<br />
| Tools<br />
| <br />
* Code reasonably well in the languages required for the task.<br />
* Correctly use a command-line interface.<br />
* Correctly use the basics of version control including branching and merging.<br />
* Create a correct patch or pull request.<br />
|-<br />
| Software Configuration<br />
| <br />
* Download and install the development environment.<br />
* Run the program.<br />
* Complete the [[:Category:Test_User_Installation_Instructions_(Pathway)|Test User Installation Instructions]] pathway.<br />
|-<br />
| Issue Tracker<br />
|<br />
* Describe issue trackers and how they are used.<br />
* Access the issue tracker with appropriate permissions.<br />
* Read, create, and update issues in a tracker.<br />
* Complete the [[:Category:Update_a_Tracker_Issue_(Pathway)|Update a Tracker Issue]] pathway.<br />
|-<br />
| Community<br />
| <br />
* Contact community members for help and identify the person responsible for committing changes.<br />
* Describe community policy on testing and submitting patches/code, understand issue solving/triaging process.<br />
* Participate in a community which is open to code contributions.<br />
* Time a contribution within the project's release cycle.<br />
|}<br />
<br />
=== Pathway Steps, Outcomes, & Learning Activities ===<br />
<br />
Follow the project’s policies and practices to complete the steps below.<br />
<br />
{| {{Pathway Step Table}}<br />
| 1. Identify feature to be coded.<br />
: - explore tickets in feature tracker<br />
: - discuss with community<br />
| Feature identified.<br />
|<br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Critical Thinking|Crit Think]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Requirements_Analysis|Requirements analysis]]<br />
* TBD: identify feature to be implemented<br />
* [[Code_Base_Understanding|Code base understanding]]<br />
|-<br />
| 2. Claim the ticket for the feature.<br />
: - create ticket if necessary.<br />
| Ticket for feature is claimed.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Handle_an_OpenMRS_Ticket_(Activity)|Handle an OpenMRS ticket]]<br />
|-<br />
| 3. Implement feature.<br />
| Code to implement feature is complete.<br />
: - Possibly: Test cases for feature are complete.<br />
| <br />
* [[:Category:Problem Solving|Prob Solv]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
* [[:Category:Management|Mgmt]]<br />
|<br />
* [[Introduction_to_Test_Driven_Development| Intro to test driven development]]<br />
* [[Test_Driven_Development|Test driven development]]<br />
* [[Review_Coding_Conventions|Review coding conventions]]<br />
* [[Document_Code_with_Meaningful_Comments_(Activity)|Document code]]<br />
* [[Unit_Test_With_GoogleTest_Activity|Unit testing with GoogleTest]]<br />
* [[Examine_Branch_Test_Coverage_(Activity)|Examine branch test coverage]]<br />
|-<br />
| 4. Submit changes to community.<br />
| Code to implement the feature is accepted into the project’s codebase, or the feature is abandoned. Note: There may need to be several iterations of this process until resolution one way or another is reached.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Git:_GitHub_Workflow_Activity|GitHub workflows]]<br />
* [[Git:_GitHub_Issues_and_Pull_Requests|GitHub issues and PRs]]<br />
|-<br />
| 5. Complete process to close ticket.<br />
| Ticket for feature is closed either by the participant or by a maintainer.<br />
| <br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Handle_an_OpenMRS_Ticket_(Activity)|Handle an OpenMRS ticket]]<br />
|}<br />
<br />
=== Notes for Learning Activities Related to this Pathway ===<br />
<br />
When creating activities:<br />
<br />
# Identify reasonable features to be implemented. This can reduce student time searching for issues, and reduce the chances of choosing a feature that is too difficult or too easy.<br />
<br />
[[Category:Pathways]]<br />
[[Category:Critical Thinking]]<br />
[[Category:Information Processing]]<br />
[[Category:Management]]<br />
[[Category:Problem Solving]]<br />
[[Category:Written Communication]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Category:Add_a_Feature_(Pathway)Category:Add a Feature (Pathway)2017-03-09T00:01:49Z<p>Cmurphy: /* Prerequisites */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''The contributor will''': contribute code to implement a requested feature.<br />
'''The contribution is''': code accepted into the project's codebase to implement a requested feature.<br />
<br />
=== Prerequisites ===<br />
<br />
{| {{Pathway Prerequisite Table}}<br />
| Tools<br />
| <br />
* Code reasonably well in the languages required for the task.<br />
* Correctly use a command-line interface.<br />
* Correctly use the basics of version control including branching and merging.<br />
* Create a correct patch or pull request.<br />
|-<br />
| Software Configuration<br />
| <br />
* Download and install the development environment.<br />
* Run the program.<br />
* Complete the [[:Category:Test_User_Installation_Instructions_(Pathway)|Test User Installation Instructions]] pathway<br />
|-<br />
| Issue Tracker<br />
|<br />
* Describe issue trackers and how they are used.<br />
* Access the issue tracker with appropriate permissions.<br />
* Read, create, and update issues in a tracker.<br />
* Complete the [[:Category:Update_a_Tracker_Issue_(Pathway)|Update a Tracker Issue]] pathway<br />
|-<br />
| Community<br />
| <br />
* Contact community members for help and identify the person responsible for committing changes.<br />
* Describe community policy on testing and submitting patches/code, understand issue solving/triaging process.<br />
* Participate in a community which is open to code contributions.<br />
* Time a contribution within the project's release cycle.<br />
|}<br />
<br />
=== Pathway Steps, Outcomes, & Learning Activities ===<br />
<br />
Follow the project’s policies and practices to complete the steps below.<br />
<br />
{| {{Pathway Step Table}}<br />
| 1. Identify feature to be coded.<br />
: - explore tickets in feature tracker<br />
: - discuss with community<br />
| Feature identified.<br />
|<br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Critical Thinking|Crit Think]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Requirements_Analysis|Requirements analysis]]<br />
* TBD: identify feature to be implemented<br />
* [[Code_Base_Understanding|Code base understanding]]<br />
|-<br />
| 2. Claim the ticket for the feature.<br />
: - create ticket if necessary.<br />
| Ticket for feature is claimed.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Handle_an_OpenMRS_Ticket_(Activity)|Handle an OpenMRS ticket]]<br />
|-<br />
| 3. Implement feature.<br />
| Code to implement feature is complete.<br />
: - Possibly: Test cases for feature are complete.<br />
| <br />
* [[:Category:Problem Solving|Prob Solv]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
* [[:Category:Management|Mgmt]]<br />
|<br />
* [[Introduction_to_Test_Driven_Development| Intro to test driven development]]<br />
* [[Test_Driven_Development|Test driven development]]<br />
* [[Review_Coding_Conventions|Review coding conventions]]<br />
* [[Document_Code_with_Meaningful_Comments_(Activity)|Document code]]<br />
* [[Unit_Test_With_GoogleTest_Activity|Unit testing with GoogleTest]]<br />
* [[Examine_Branch_Test_Coverage_(Activity)|Examine branch test coverage]]<br />
|-<br />
| 4. Submit changes to community.<br />
| Code to implement the feature is accepted into the project’s codebase, or the feature is abandoned. Note: There may need to be several iterations of this process until resolution one way or another is reached.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Git:_GitHub_Workflow_Activity|GitHub workflows]]<br />
* [[Git:_GitHub_Issues_and_Pull_Requests|GitHub issues and PRs]]<br />
|-<br />
| 5. Complete process to close ticket.<br />
| Ticket for feature is closed either by the participant or by a maintainer.<br />
| <br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Handle_an_OpenMRS_Ticket_(Activity)|Handle an OpenMRS ticket]]<br />
|}<br />
<br />
=== Notes for Learning Activities Related to this Pathway ===<br />
<br />
When creating activities:<br />
<br />
# Identify reasonable features to be implemented. This can reduce student time searching for issues, and reduce the chances of choosing a feature that is too difficult or too easy.<br />
<br />
[[Category:Pathways]]<br />
[[Category:Critical Thinking]]<br />
[[Category:Information Processing]]<br />
[[Category:Management]]<br />
[[Category:Problem Solving]]<br />
[[Category:Written Communication]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Category:Add_a_Feature_(Pathway)Category:Add a Feature (Pathway)2017-03-09T00:00:56Z<p>Cmurphy: /* Prerequisites */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''The contributor will''': contribute code to implement a requested feature.<br />
'''The contribution is''': code accepted into the project's codebase to implement a requested feature.<br />
<br />
=== Prerequisites ===<br />
<br />
{| {{Pathway Prerequisite Table}}<br />
| Tools<br />
| <br />
* Code reasonably well in the languages required for the task.<br />
* Correctly use a command-line interface.<br />
* Correctly use the basics of version control including branching and merging.<br />
* Create a correct patch or pull request.<br />
|-<br />
| Software Configuration<br />
| <br />
* Download and install the development environment.<br />
* Run the program.<br />
|-<br />
| Issue Tracker<br />
|<br />
* Describe issue trackers and how they are used.<br />
* Access the issue tracker with appropriate permissions.<br />
* Read, create, and update issues in a tracker.<br />
* Complete the [[:Category:Update_a_Tracker_Issue_(Pathway)|Update a Tracker Issue]] pathway<br />
|-<br />
| Community<br />
| <br />
* Contact community members for help and identify the person responsible for committing changes.<br />
* Describe community policy on testing and submitting patches/code, understand issue solving/triaging process.<br />
* Participate in a community which is open to code contributions.<br />
* Time a contribution within the project's release cycle.<br />
|}<br />
<br />
=== Pathway Steps, Outcomes, & Learning Activities ===<br />
<br />
Follow the project’s policies and practices to complete the steps below.<br />
<br />
{| {{Pathway Step Table}}<br />
| 1. Identify feature to be coded.<br />
: - explore tickets in feature tracker<br />
: - discuss with community<br />
| Feature identified.<br />
|<br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Critical Thinking|Crit Think]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Requirements_Analysis|Requirements analysis]]<br />
* TBD: identify feature to be implemented<br />
* [[Code_Base_Understanding|Code base understanding]]<br />
|-<br />
| 2. Claim the ticket for the feature.<br />
: - create ticket if necessary.<br />
| Ticket for feature is claimed.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Handle_an_OpenMRS_Ticket_(Activity)|Handle an OpenMRS ticket]]<br />
|-<br />
| 3. Implement feature.<br />
| Code to implement feature is complete.<br />
: - Possibly: Test cases for feature are complete.<br />
| <br />
* [[:Category:Problem Solving|Prob Solv]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
* [[:Category:Management|Mgmt]]<br />
|<br />
* [[Introduction_to_Test_Driven_Development| Intro to test driven development]]<br />
* [[Test_Driven_Development|Test driven development]]<br />
* [[Review_Coding_Conventions|Review coding conventions]]<br />
* [[Document_Code_with_Meaningful_Comments_(Activity)|Document code]]<br />
* [[Unit_Test_With_GoogleTest_Activity|Unit testing with GoogleTest]]<br />
* [[Examine_Branch_Test_Coverage_(Activity)|Examine branch test coverage]]<br />
|-<br />
| 4. Submit changes to community.<br />
| Code to implement the feature is accepted into the project’s codebase, or the feature is abandoned. Note: There may need to be several iterations of this process until resolution one way or another is reached.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Git:_GitHub_Workflow_Activity|GitHub workflows]]<br />
* [[Git:_GitHub_Issues_and_Pull_Requests|GitHub issues and PRs]]<br />
|-<br />
| 5. Complete process to close ticket.<br />
| Ticket for feature is closed either by the participant or by a maintainer.<br />
| <br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Handle_an_OpenMRS_Ticket_(Activity)|Handle an OpenMRS ticket]]<br />
|}<br />
<br />
=== Notes for Learning Activities Related to this Pathway ===<br />
<br />
When creating activities:<br />
<br />
# Identify reasonable features to be implemented. This can reduce student time searching for issues, and reduce the chances of choosing a feature that is too difficult or too easy.<br />
<br />
[[Category:Pathways]]<br />
[[Category:Critical Thinking]]<br />
[[Category:Information Processing]]<br />
[[Category:Management]]<br />
[[Category:Problem Solving]]<br />
[[Category:Written Communication]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Category:Add_a_Feature_(Pathway)Category:Add a Feature (Pathway)2017-03-08T23:59:39Z<p>Cmurphy: /* Prerequisites */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''The contributor will''': contribute code to implement a requested feature.<br />
'''The contribution is''': code accepted into the project's codebase to implement a requested feature.<br />
<br />
=== Prerequisites ===<br />
<br />
{| {{Pathway Prerequisite Table}}<br />
| Tools<br />
| <br />
* Code reasonably well in the languages required for the task.<br />
* Correctly use a command-line interface.<br />
* Correctly use the basics of version control including branching and merging.<br />
* Create a correct patch or pull request.<br />
|-<br />
| Software Configuration<br />
| <br />
* Download and install the development environment.<br />
* Run the program.<br />
|-<br />
| Issue Tracker<br />
|<br />
* Describe issue trackers and how they are used.<br />
* Access the issue tracker with appropriate permissions.<br />
* Read, create, and update issues in a tracker.<br />
* Complete the [[Category:Create_a_Tracker_Issue_(Pathway)|Create a Tracker Issue]] pathway<br />
|-<br />
| Community<br />
| <br />
* Contact community members for help and identify the person responsible for committing changes.<br />
* Describe community policy on testing and submitting patches/code, understand issue solving/triaging process.<br />
* Participate in a community which is open to code contributions.<br />
* Time a contribution within the project's release cycle.<br />
|}<br />
<br />
=== Pathway Steps, Outcomes, & Learning Activities ===<br />
<br />
Follow the project’s policies and practices to complete the steps below.<br />
<br />
{| {{Pathway Step Table}}<br />
| 1. Identify feature to be coded.<br />
: - explore tickets in feature tracker<br />
: - discuss with community<br />
| Feature identified.<br />
|<br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Critical Thinking|Crit Think]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Requirements_Analysis|Requirements analysis]]<br />
* TBD: identify feature to be implemented<br />
* [[Code_Base_Understanding|Code base understanding]]<br />
|-<br />
| 2. Claim the ticket for the feature.<br />
: - create ticket if necessary.<br />
| Ticket for feature is claimed.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Handle_an_OpenMRS_Ticket_(Activity)|Handle an OpenMRS ticket]]<br />
|-<br />
| 3. Implement feature.<br />
| Code to implement feature is complete.<br />
: - Possibly: Test cases for feature are complete.<br />
| <br />
* [[:Category:Problem Solving|Prob Solv]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
* [[:Category:Management|Mgmt]]<br />
|<br />
* [[Introduction_to_Test_Driven_Development| Intro to test driven development]]<br />
* [[Test_Driven_Development|Test driven development]]<br />
* [[Review_Coding_Conventions|Review coding conventions]]<br />
* [[Document_Code_with_Meaningful_Comments_(Activity)|Document code]]<br />
* [[Unit_Test_With_GoogleTest_Activity|Unit testing with GoogleTest]]<br />
* [[Examine_Branch_Test_Coverage_(Activity)|Examine branch test coverage]]<br />
|-<br />
| 4. Submit changes to community.<br />
| Code to implement the feature is accepted into the project’s codebase, or the feature is abandoned. Note: There may need to be several iterations of this process until resolution one way or another is reached.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Git:_GitHub_Workflow_Activity|GitHub workflows]]<br />
* [[Git:_GitHub_Issues_and_Pull_Requests|GitHub issues and PRs]]<br />
|-<br />
| 5. Complete process to close ticket.<br />
| Ticket for feature is closed either by the participant or by a maintainer.<br />
| <br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Handle_an_OpenMRS_Ticket_(Activity)|Handle an OpenMRS ticket]]<br />
|}<br />
<br />
=== Notes for Learning Activities Related to this Pathway ===<br />
<br />
When creating activities:<br />
<br />
# Identify reasonable features to be implemented. This can reduce student time searching for issues, and reduce the chances of choosing a feature that is too difficult or too easy.<br />
<br />
[[Category:Pathways]]<br />
[[Category:Critical Thinking]]<br />
[[Category:Information Processing]]<br />
[[Category:Management]]<br />
[[Category:Problem Solving]]<br />
[[Category:Written Communication]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Category_talk:Add_a_Feature_(Pathway)Category talk:Add a Feature (Pathway)2017-03-08T23:55:34Z<p>Cmurphy: </p>
<hr />
<div>Need to have an "Identify a Feature to be Added" activity based on assessing the current feature set (for Step 1)<br />
<br />
There may be some differences in Steps 4 and 5 depending on the community and the tools, e.g. the student may not be able to close the ticket.</div>Cmurphyhttp://www.foss2serve.org/index.php/Category_talk:Add_a_Feature_(Pathway)Category talk:Add a Feature (Pathway)2017-03-08T23:49:29Z<p>Cmurphy: Created page with "Need to have an "Identify a Feature to be Added" activity based on assessing the current feature set"</p>
<hr />
<div>Need to have an "Identify a Feature to be Added" activity based on assessing the current feature set</div>Cmurphyhttp://www.foss2serve.org/index.php/SIGCSE_2017_POSSE_RoundupSIGCSE 2017 POSSE Roundup2017-03-08T22:48:22Z<p>Cmurphy: /* Agenda */</p>
<hr />
<div>__NOTOC__<br />
<br />
=== Overview ===<br />
<br />
POSSE, the Professors Open Source Software Experience, helps instructors prepare to guide student participation in Humanitarian Free and Open Source Software (HFOSS) projects. This POSSE Roundup is a workshop for instructors who have previously attended POSSE. It will provide an opportunity to share experiences and discuss challenges with student participation in HFOSS. There will also be presentations and discussions of recent developments in HFOSS learning efforts. The workshop structure of the day will emphasize active participation of attendees.<br />
<br />
=== Notes ===<br />
[https://titanpad.com/SIGCSE-2017-POSSE-Roundup TitanPad]<br />
<br />
=== Meeting Location ===<br />
'''Washington Convention Center rooms 613 and 614'''<br />
<br />
=== Agenda ===<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Activity<br />
! Facilitators<br />
|-<br />
|<br />
! Wednesday March 8th, 2017<br />
|<br />
|-<br />
| 8:30 AM<br />
| <br />
Welcome and Overview:<br />
* Introductions<br />
* Plan for the day<br />
* Pathways Overview<br />
| Lori and Greg<br />
|-<br />
| 9:15 AM<br />
| <br />
Breakout: Quick assessment of existing learning activities<br />
| Darci<br />
|-<br />
| 10:00 AM<br />
| Break<br />
| All<br />
|-<br />
| 10:30 AM<br />
|<br />
Breakout: Matching learning activities to pathway steps <br />
| Greg<br />
|-<br />
| 11:30<br />
| Lunch - http://www.sheratonseattle.com/daily-grill-lunch<br />
| All<br />
|-<br />
| 1:00 PM<br />
|<br />
Experience Reports and Perspectives<br />
* Grant Braught and John MacCormick<br />
* Chris Murphy ([http://www.seas.upenn.edu/~cdmurphy/foss/Murphy-POSSERoundup-Mar2017.pptx slides])<br />
* Karl Wurst<br />
| Darci<br />
|-<br />
| 2:00 PM<br />
|<br />
Report on morning progress<br />
Breakout: Learning activity review or design<br />
* Evaluate existing activities for pathway use<br />
* Identify additional activities where needed<br />
| Heidi<br />
|-<br />
| 3:00 PM<br />
| Break<br />
| <br />
|-<br />
| 3:30 PM<br />
| <br />
Breakout group status<br />
| Heidi<br />
|-<br />
| 3:45 PM<br />
| <br />
Breakout: Learning Materials Sprint<br />
* Work on learning activities identified in the morning<br />
| Heidi<br />
|-<br />
| 4:45 PM<br />
| Wrap-up<br />
* POGIL Summer workshops<br />
| Greg and Lori<br />
|-<br />
| 6:00 PM<br />
| Dinner<br />
* [http://tuttabella.com/ Tutta Bella], 2200 Westlake Ave, Seattle, WA 98121<br />
| All<br />
|-<br />
|}<br />
<br />
<br style="clear:both;"><br />
<br />
=== Preparation ===<br />
<br />
We are going to spend time working with the contribution pathways. Initial versions of some pathways are [http://foss2serve.org/index.php/Category:Pathways here]<br />
<br />
In preparation for the Roundup, please pick one pathway that you would be interested in working with at the Roundup. Indicate your choice by adding your name below:<br />
<br />
* Add a Feature <br />
** Amy Csizmar Dalal<br />
** Chris Murphy<br />
** Karl Wurst<br />
<br />
* Create a Tracker Issue<br />
**Gina (or will work on tos.org)<br />
**Darci Burdge<br />
<br />
* Create Unit Tests<br />
**John MacCormick<br />
**Josh Dehlinger<br />
<br />
* Fix a Bug<br />
**Becka Morgan<br />
**Nanette Veilleux <br />
**Lynn Lambert<br />
<br />
* Test User Installation Instructions<br />
** Greg Hislop<br />
** Joanna Klukowska<br />
** Stewart Weiss<br />
<br />
* Update a Tracker Issue<br />
** Emily Lovell<br />
** Heidi Ellis<br />
<br />
* Verify a Bug<br />
** Lori Postner<br />
** Grant Braught<br />
<br />
=== Triage of Existing Activities ===<br />
<br />
During the 9:15am session participants will work in pairs to triage approximately 10 existing foss2serve learning activities. A complete list of learning activities can be found at: http://foss2serve.org/index.php/Category:Learning_Activity<br />
For each activity, spend 3-5 to minutes reviewing it and adding a Category tag of "Minimal Sketch", "Good Draft", "Ready to Use".<br />
Please put any comments you have about the activity in the Discussion page for that activity.<br />
* Group 1: Backwardly Compatible Code (Activity) - Choosing A License -- Chris & Lori<br />
* Group 2: Code Base Understanding - Examine Branch Test Coverage (Activity) -- Josh & Helen<br />
* Group 3: Fedora 22 in VirtualBox Set up - FOSS Politics Writing Activity -- Ben and Karl<br />
* Group 4: Git: Cloning - Instantly Run An App in the Cloud 2<br />
* Group 5: Interactive Visualization with Git - Intro to Style Guides (Activity) -- Stewart and Joanna<br />
* Group 6: Introduction to building open source software - Open Vs Proprietary Mock Debate (skip the learning activity rubric links) - Darci & John<br />
* Group 7: OpenMRS Design Reverse Engineering Activity (Android App) - OpenMRS.Setup - Greg<br />
* Group 8: Origins of Free Libre Software - Review Coding Conventions - Becka and Heidi<br />
* Group 9: Software Design Architecture Comparison - UML a project Lynn and Amy<br />
* Group 10: Understanding Creative Commons - Write a Bug Report (Activity) - Emily & Gina<br />
<br />
=== Information for Attendees ===<br />
<br />
===== To Register =====<br />
<br />
Attendees of past POSSEs who are able to attend should register by emailing Lori Postner at Lori.Postner@ncc.edu or Greg Hislop at hislop@drexel.edu<br />
<br />
===== Support =====<br />
<br />
We expect that most attendees will be staying for SIGCSE. For those needing to arrive on Tuesday to attend the POSSE roundup on Wednesday, we can provide support for the extra hotel night for a limited number of attendees. Please let us know ASAP if you are interested in this support.<br />
<br />
<br />
[[Category:Events]]<br />
[[Category:Workshops]]</div>Cmurphyhttp://www.foss2serve.org/index.php/SIGCSE_2017_POSSE_RoundupSIGCSE 2017 POSSE Roundup2017-03-08T22:47:47Z<p>Cmurphy: /* Agenda */</p>
<hr />
<div>__NOTOC__<br />
<br />
=== Overview ===<br />
<br />
POSSE, the Professors Open Source Software Experience, helps instructors prepare to guide student participation in Humanitarian Free and Open Source Software (HFOSS) projects. This POSSE Roundup is a workshop for instructors who have previously attended POSSE. It will provide an opportunity to share experiences and discuss challenges with student participation in HFOSS. There will also be presentations and discussions of recent developments in HFOSS learning efforts. The workshop structure of the day will emphasize active participation of attendees.<br />
<br />
=== Notes ===<br />
[https://titanpad.com/SIGCSE-2017-POSSE-Roundup TitanPad]<br />
<br />
=== Meeting Location ===<br />
'''Washington Convention Center rooms 613 and 614'''<br />
<br />
=== Agenda ===<br />
<br />
{| class="wikitable"<br />
! Time<br />
! Activity<br />
! Facilitators<br />
|-<br />
|<br />
! Wednesday March 8th, 2017<br />
|<br />
|-<br />
| 8:30 AM<br />
| <br />
Welcome and Overview:<br />
* Introductions<br />
* Plan for the day<br />
* Pathways Overview<br />
| Lori and Greg<br />
|-<br />
| 9:15 AM<br />
| <br />
Breakout: Quick assessment of existing learning activities<br />
| Darci<br />
|-<br />
| 10:00 AM<br />
| Break<br />
| All<br />
|-<br />
| 10:30 AM<br />
|<br />
Breakout: Matching learning activities to pathway steps <br />
| Greg<br />
|-<br />
| 11:30<br />
| Lunch - http://www.sheratonseattle.com/daily-grill-lunch<br />
| All<br />
|-<br />
| 1:00 PM<br />
|<br />
Experience Reports and Perspectives<br />
* Grant Braught and John MacCormick<br />
* Chris Murphy [[http://www.seas.upenn.edu/~cdmurphy/foss/Murphy-POSSERoundup-Mar2017.pptx|slides]]<br />
* Karl Wurst<br />
| Darci<br />
|-<br />
| 2:00 PM<br />
|<br />
Report on morning progress<br />
Breakout: Learning activity review or design<br />
* Evaluate existing activities for pathway use<br />
* Identify additional activities where needed<br />
| Heidi<br />
|-<br />
| 3:00 PM<br />
| Break<br />
| <br />
|-<br />
| 3:30 PM<br />
| <br />
Breakout group status<br />
| Heidi<br />
|-<br />
| 3:45 PM<br />
| <br />
Breakout: Learning Materials Sprint<br />
* Work on learning activities identified in the morning<br />
| Heidi<br />
|-<br />
| 4:45 PM<br />
| Wrap-up<br />
* POGIL Summer workshops<br />
| Greg and Lori<br />
|-<br />
| 6:00 PM<br />
| Dinner<br />
* [http://tuttabella.com/ Tutta Bella], 2200 Westlake Ave, Seattle, WA 98121<br />
| All<br />
|-<br />
|}<br />
<br />
<br style="clear:both;"><br />
<br />
=== Preparation ===<br />
<br />
We are going to spend time working with the contribution pathways. Initial versions of some pathways are [http://foss2serve.org/index.php/Category:Pathways here]<br />
<br />
In preparation for the Roundup, please pick one pathway that you would be interested in working with at the Roundup. Indicate your choice by adding your name below:<br />
<br />
* Add a Feature <br />
** Amy Csizmar Dalal<br />
** Chris Murphy<br />
** Karl Wurst<br />
<br />
* Create a Tracker Issue<br />
**Gina (or will work on tos.org)<br />
**Darci Burdge<br />
<br />
* Create Unit Tests<br />
**John MacCormick<br />
**Josh Dehlinger<br />
<br />
* Fix a Bug<br />
**Becka Morgan<br />
**Nanette Veilleux <br />
**Lynn Lambert<br />
<br />
* Test User Installation Instructions<br />
** Greg Hislop<br />
** Joanna Klukowska<br />
** Stewart Weiss<br />
<br />
* Update a Tracker Issue<br />
** Emily Lovell<br />
** Heidi Ellis<br />
<br />
* Verify a Bug<br />
** Lori Postner<br />
** Grant Braught<br />
<br />
=== Triage of Existing Activities ===<br />
<br />
During the 9:15am session participants will work in pairs to triage approximately 10 existing foss2serve learning activities. A complete list of learning activities can be found at: http://foss2serve.org/index.php/Category:Learning_Activity<br />
For each activity, spend 3-5 to minutes reviewing it and adding a Category tag of "Minimal Sketch", "Good Draft", "Ready to Use".<br />
Please put any comments you have about the activity in the Discussion page for that activity.<br />
* Group 1: Backwardly Compatible Code (Activity) - Choosing A License -- Chris & Lori<br />
* Group 2: Code Base Understanding - Examine Branch Test Coverage (Activity) -- Josh & Helen<br />
* Group 3: Fedora 22 in VirtualBox Set up - FOSS Politics Writing Activity -- Ben and Karl<br />
* Group 4: Git: Cloning - Instantly Run An App in the Cloud 2<br />
* Group 5: Interactive Visualization with Git - Intro to Style Guides (Activity) -- Stewart and Joanna<br />
* Group 6: Introduction to building open source software - Open Vs Proprietary Mock Debate (skip the learning activity rubric links) - Darci & John<br />
* Group 7: OpenMRS Design Reverse Engineering Activity (Android App) - OpenMRS.Setup - Greg<br />
* Group 8: Origins of Free Libre Software - Review Coding Conventions - Becka and Heidi<br />
* Group 9: Software Design Architecture Comparison - UML a project Lynn and Amy<br />
* Group 10: Understanding Creative Commons - Write a Bug Report (Activity) - Emily & Gina<br />
<br />
=== Information for Attendees ===<br />
<br />
===== To Register =====<br />
<br />
Attendees of past POSSEs who are able to attend should register by emailing Lori Postner at Lori.Postner@ncc.edu or Greg Hislop at hislop@drexel.edu<br />
<br />
===== Support =====<br />
<br />
We expect that most attendees will be staying for SIGCSE. For those needing to arrive on Tuesday to attend the POSSE roundup on Wednesday, we can provide support for the extra hotel night for a limited number of attendees. Please let us know ASAP if you are interested in this support.<br />
<br />
<br />
[[Category:Events]]<br />
[[Category:Workshops]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Category:Add_a_Feature_(Pathway)Category:Add a Feature (Pathway)2017-03-08T19:33:11Z<p>Cmurphy: /* Pathway Steps, Outcomes, & Learning Activities */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''The contributor will''': contribute code to implement a requested feature.<br />
'''The contribution is''': code accepted into the project's codebase to implement a requested feature.<br />
<br />
=== Prerequisites ===<br />
<br />
{| {{Pathway Prerequisite Table}}<br />
| Tools<br />
| <br />
* Code reasonably well in the languages required for the task.<br />
* Correctly use a command-line interface.<br />
* Correctly use the basics of version control including branching and merging.<br />
* Create a correct patch or pull request.<br />
|-<br />
| Software Configuration<br />
| <br />
* Download and install the development environment.<br />
* Run the program.<br />
|-<br />
| Issue Tracker<br />
|<br />
* Describe issue trackers and how they are used.<br />
* Access the issue tracker with appropriate permissions.<br />
* Read, create, and update issues in a tracker.<br />
|-<br />
| Community<br />
| <br />
* Contact community members for help and identify the person responsible for committing changes.<br />
* Describe community policy on testing and submitting patches/code, understand issue solving/triaging process.<br />
* Participate in a community which is open to code contributions.<br />
* Time a contribution within the project's release cycle.<br />
|}<br />
<br />
=== Pathway Steps, Outcomes, & Learning Activities ===<br />
<br />
Follow the project’s policies and practices to complete the steps below.<br />
<br />
{| {{Pathway Step Table}}<br />
| 1. Identify feature to be coded.<br />
: - explore tickets in feature tracker<br />
: - discuss with community<br />
| Feature identified.<br />
|<br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Critical Thinking|Crit Think]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Requirements_Analysis|Requirements analysis]]<br />
* TBD: identify feature to be implemented<br />
* [[Code_Base_Understanding|Code base understanding]]<br />
|-<br />
| 2. Claim the ticket for the feature.<br />
: - create ticket if necessary.<br />
| Ticket for feature is claimed.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Handle_an_OpenMRS_Ticket_(Activity)|Handle an OpenMRS ticket]]<br />
|-<br />
| 3. Implement feature.<br />
| Code to implement feature is complete.<br />
: - Possibly: Test cases for feature are complete.<br />
| <br />
* [[:Category:Problem Solving|Prob Solv]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
* [[:Category:Management|Mgmt]]<br />
|<br />
* [[Introduction_to_Test_Driven_Development| Intro to test driven development]]<br />
* [[Test_Driven_Development|Test driven development]]<br />
* [[Review_Coding_Conventions|Review coding conventions]]<br />
* [[Document_Code_with_Meaningful_Comments_(Activity)|Document code]]<br />
* [[Unit_Test_With_GoogleTest_Activity|Unit testing with GoogleTest]]<br />
* [[Examine_Branch_Test_Coverage_(Activity)|Examine branch test coverage]]<br />
|-<br />
| 4. Submit changes to community.<br />
| Code to implement the feature is accepted into the project’s codebase, or the feature is abandoned.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Git:_GitHub_Workflow_Activity|GitHub workflows]]<br />
* [[Git:_GitHub_Issues_and_Pull_Requests|GitHub issues and PRs]]<br />
|-<br />
| 5. Complete process to close ticket.<br />
| Ticket for feature is closed.<br />
| <br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Handle_an_OpenMRS_Ticket_(Activity)|Handle an OpenMRS ticket]]<br />
|}<br />
<br />
=== Notes for Learning Activities Related to this Pathway ===<br />
<br />
When creating activities:<br />
<br />
# Identify reasonable features to be implemented. This can reduce student time searching for issues, and reduce the chances of choosing a feature that is too difficult or too easy.<br />
<br />
[[Category:Pathways]]<br />
[[Category:Critical Thinking]]<br />
[[Category:Information Processing]]<br />
[[Category:Management]]<br />
[[Category:Problem Solving]]<br />
[[Category:Written Communication]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Category:Add_a_Feature_(Pathway)Category:Add a Feature (Pathway)2017-03-08T19:32:29Z<p>Cmurphy: /* Pathway Steps, Outcomes, & Learning Activities */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''The contributor will''': contribute code to implement a requested feature.<br />
'''The contribution is''': code accepted into the project's codebase to implement a requested feature.<br />
<br />
=== Prerequisites ===<br />
<br />
{| {{Pathway Prerequisite Table}}<br />
| Tools<br />
| <br />
* Code reasonably well in the languages required for the task.<br />
* Correctly use a command-line interface.<br />
* Correctly use the basics of version control including branching and merging.<br />
* Create a correct patch or pull request.<br />
|-<br />
| Software Configuration<br />
| <br />
* Download and install the development environment.<br />
* Run the program.<br />
|-<br />
| Issue Tracker<br />
|<br />
* Describe issue trackers and how they are used.<br />
* Access the issue tracker with appropriate permissions.<br />
* Read, create, and update issues in a tracker.<br />
|-<br />
| Community<br />
| <br />
* Contact community members for help and identify the person responsible for committing changes.<br />
* Describe community policy on testing and submitting patches/code, understand issue solving/triaging process.<br />
* Participate in a community which is open to code contributions.<br />
* Time a contribution within the project's release cycle.<br />
|}<br />
<br />
=== Pathway Steps, Outcomes, & Learning Activities ===<br />
<br />
Follow the project’s policies and practices to complete the steps below.<br />
<br />
{| {{Pathway Step Table}}<br />
| 1. Identify feature to be coded.<br />
: - explore tickets in feature tracker<br />
: - discuss with community<br />
| Feature identified.<br />
|<br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Critical Thinking|Crit Think]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Requirements_Analysis|Requirements analysis]]<br />
* TBD: identify feature to be implemented<br />
* [[Code_Base_Understanding|Code base understanding]]<br />
|-<br />
| 2. Claim the ticket for the feature.<br />
: - create ticket if necessary.<br />
| Ticket for feature is claimed.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Handle_an_OpenMRS_Ticket_(Activity)|Handle an OpenMRS ticket]]<br />
|-<br />
| 3. Implement feature.<br />
| Code to implement feature is complete.<br />
: - Possibly: Test cases for feature are complete.<br />
| <br />
* [[:Category:Problem Solving|Prob Solv]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
* [[:Category:Management|Mgmt]]<br />
|<br />
* [[Introduction_to_Test_Driven_Development| Intro to test driven development]]<br />
* [[Test_Driven_Development|Test driven development]]<br />
* [[Review_Coding_Conventions|Review coding conventions]]<br />
* [[Document_Code_with_Meaningful_Comments_(Activity)|Document code]]<br />
* [[Unit_Test_With_GoogleTest_Activity|Unit testing with GoogleTest]]<br />
* [[Examine_Branch_Test_Coverage_(Activity)|Examine branch test coverage]]<br />
|-<br />
| 4. Submit changes to community.<br />
| Code to implement the feature is accepted into the project’s codebase, or the feature is abandoned.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Git:_GitHub_Workflow_Activity|GitHub workflows]]<br />
* [[Git:_GitHub_Issues_and_Pull_Requests|GitHub issues and PRs]]<br />
|-<br />
| 5. Complete process to close ticket.<br />
| Ticket for feature is closed.<br />
| <br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
|}<br />
<br />
=== Notes for Learning Activities Related to this Pathway ===<br />
<br />
When creating activities:<br />
<br />
# Identify reasonable features to be implemented. This can reduce student time searching for issues, and reduce the chances of choosing a feature that is too difficult or too easy.<br />
<br />
[[Category:Pathways]]<br />
[[Category:Critical Thinking]]<br />
[[Category:Information Processing]]<br />
[[Category:Management]]<br />
[[Category:Problem Solving]]<br />
[[Category:Written Communication]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Category:Add_a_Feature_(Pathway)Category:Add a Feature (Pathway)2017-03-08T19:29:54Z<p>Cmurphy: /* Pathway Steps, Outcomes, & Learning Activities */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''The contributor will''': contribute code to implement a requested feature.<br />
'''The contribution is''': code accepted into the project's codebase to implement a requested feature.<br />
<br />
=== Prerequisites ===<br />
<br />
{| {{Pathway Prerequisite Table}}<br />
| Tools<br />
| <br />
* Code reasonably well in the languages required for the task.<br />
* Correctly use a command-line interface.<br />
* Correctly use the basics of version control including branching and merging.<br />
* Create a correct patch or pull request.<br />
|-<br />
| Software Configuration<br />
| <br />
* Download and install the development environment.<br />
* Run the program.<br />
|-<br />
| Issue Tracker<br />
|<br />
* Describe issue trackers and how they are used.<br />
* Access the issue tracker with appropriate permissions.<br />
* Read, create, and update issues in a tracker.<br />
|-<br />
| Community<br />
| <br />
* Contact community members for help and identify the person responsible for committing changes.<br />
* Describe community policy on testing and submitting patches/code, understand issue solving/triaging process.<br />
* Participate in a community which is open to code contributions.<br />
* Time a contribution within the project's release cycle.<br />
|}<br />
<br />
=== Pathway Steps, Outcomes, & Learning Activities ===<br />
<br />
Follow the project’s policies and practices to complete the steps below.<br />
<br />
{| {{Pathway Step Table}}<br />
| 1. Identify feature to be coded.<br />
: - explore tickets in feature tracker<br />
: - discuss with community<br />
| Feature identified.<br />
|<br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Critical Thinking|Crit Think]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Requirements_Analysis|Requirements analysis]]<br />
* TBD: identify feature to be implemented<br />
* [[Code_Base_Understanding|Code base understanding]]<br />
|-<br />
| 2. Claim the ticket for the feature.<br />
: - create ticket if necessary.<br />
| Ticket for feature is claimed.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
|-<br />
| 3. Implement feature.<br />
| Code to implement feature is complete.<br />
: - Possibly: Test cases for feature are complete.<br />
| <br />
* [[:Category:Problem Solving|Prob Solv]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
* [[:Category:Management|Mgmt]]<br />
|<br />
* [[Introduction_to_Test_Driven_Development| Intro to test driven development]]<br />
* [[Test_Driven_Development|Test driven development]]<br />
* [[Review_Coding_Conventions|Review coding conventions]]<br />
* [[Document_Code_with_Meaningful_Comments_(Activity)|Document code]]<br />
* [[Unit_Test_With_GoogleTest_Activity|Unit testing with GoogleTest]]<br />
* [[Examine_Branch_Test_Coverage_(Activity)|Examine branch test coverage]]<br />
|-<br />
| 4. Submit changes to community.<br />
| Code to implement the feature is accepted into the project’s codebase, or the feature is abandoned.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Git:_GitHub_Workflow_Activity|GitHub workflows]]<br />
* [[Git:_GitHub_Issues_and_Pull_Requests|GitHub issues and PRs]]<br />
|-<br />
| 5. Complete process to close ticket.<br />
| Ticket for feature is closed.<br />
| <br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
|}<br />
<br />
=== Notes for Learning Activities Related to this Pathway ===<br />
<br />
When creating activities:<br />
<br />
# Identify reasonable features to be implemented. This can reduce student time searching for issues, and reduce the chances of choosing a feature that is too difficult or too easy.<br />
<br />
[[Category:Pathways]]<br />
[[Category:Critical Thinking]]<br />
[[Category:Information Processing]]<br />
[[Category:Management]]<br />
[[Category:Problem Solving]]<br />
[[Category:Written Communication]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Category:Add_a_Feature_(Pathway)Category:Add a Feature (Pathway)2017-03-08T19:27:17Z<p>Cmurphy: /* Pathway Steps, Outcomes, & Learning Activities */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''The contributor will''': contribute code to implement a requested feature.<br />
'''The contribution is''': code accepted into the project's codebase to implement a requested feature.<br />
<br />
=== Prerequisites ===<br />
<br />
{| {{Pathway Prerequisite Table}}<br />
| Tools<br />
| <br />
* Code reasonably well in the languages required for the task.<br />
* Correctly use a command-line interface.<br />
* Correctly use the basics of version control including branching and merging.<br />
* Create a correct patch or pull request.<br />
|-<br />
| Software Configuration<br />
| <br />
* Download and install the development environment.<br />
* Run the program.<br />
|-<br />
| Issue Tracker<br />
|<br />
* Describe issue trackers and how they are used.<br />
* Access the issue tracker with appropriate permissions.<br />
* Read, create, and update issues in a tracker.<br />
|-<br />
| Community<br />
| <br />
* Contact community members for help and identify the person responsible for committing changes.<br />
* Describe community policy on testing and submitting patches/code, understand issue solving/triaging process.<br />
* Participate in a community which is open to code contributions.<br />
* Time a contribution within the project's release cycle.<br />
|}<br />
<br />
=== Pathway Steps, Outcomes, & Learning Activities ===<br />
<br />
Follow the project’s policies and practices to complete the steps below.<br />
<br />
{| {{Pathway Step Table}}<br />
| 1. Identify feature to be coded.<br />
: - explore tickets in feature tracker<br />
: - discuss with community<br />
| Feature identified.<br />
|<br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Critical Thinking|Crit Think]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Requirements_Analysis|Requirements analysis]]<br />
* TBD: identify feature to be implemented<br />
|-<br />
| 2. Claim the ticket for the feature.<br />
: - create ticket if necessary.<br />
| Ticket for feature is claimed.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
|-<br />
| 3. Implement feature.<br />
| Code to implement feature is complete.<br />
: - Possibly: Test cases for feature are complete.<br />
| <br />
* [[:Category:Problem Solving|Prob Solv]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
* [[:Category:Management|Mgmt]]<br />
|<br />
* [[Introduction_to_Test_Driven_Development| Intro to test driven development]]<br />
* [[Test_Driven_Development|Test driven development]]<br />
* [[Review_Coding_Conventions|Review coding conventions]]<br />
* [[Document_Code_with_Meaningful_Comments_(Activity)|Document code]]<br />
* [[Unit_Test_With_GoogleTest_Activity|Unit testing with GoogleTest]]<br />
* [[Examine_Branch_Test_Coverage_(Activity)|Examine branch test coverage]]<br />
|-<br />
| 4. Submit changes to community.<br />
| Code to implement the feature is accepted into the project’s codebase, or the feature is abandoned.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Git:_GitHub_Workflow_Activity|GitHub workflows]]<br />
* [[Git:_GitHub_Issues_and_Pull_Requests|GitHub issues and PRs]]<br />
|-<br />
| 5. Complete process to close ticket.<br />
| Ticket for feature is closed.<br />
| <br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
|}<br />
<br />
=== Notes for Learning Activities Related to this Pathway ===<br />
<br />
When creating activities:<br />
<br />
# Identify reasonable features to be implemented. This can reduce student time searching for issues, and reduce the chances of choosing a feature that is too difficult or too easy.<br />
<br />
[[Category:Pathways]]<br />
[[Category:Critical Thinking]]<br />
[[Category:Information Processing]]<br />
[[Category:Management]]<br />
[[Category:Problem Solving]]<br />
[[Category:Written Communication]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Category:Add_a_Feature_(Pathway)Category:Add a Feature (Pathway)2017-03-08T19:26:53Z<p>Cmurphy: /* Pathway Steps, Outcomes, & Learning Activities */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''The contributor will''': contribute code to implement a requested feature.<br />
'''The contribution is''': code accepted into the project's codebase to implement a requested feature.<br />
<br />
=== Prerequisites ===<br />
<br />
{| {{Pathway Prerequisite Table}}<br />
| Tools<br />
| <br />
* Code reasonably well in the languages required for the task.<br />
* Correctly use a command-line interface.<br />
* Correctly use the basics of version control including branching and merging.<br />
* Create a correct patch or pull request.<br />
|-<br />
| Software Configuration<br />
| <br />
* Download and install the development environment.<br />
* Run the program.<br />
|-<br />
| Issue Tracker<br />
|<br />
* Describe issue trackers and how they are used.<br />
* Access the issue tracker with appropriate permissions.<br />
* Read, create, and update issues in a tracker.<br />
|-<br />
| Community<br />
| <br />
* Contact community members for help and identify the person responsible for committing changes.<br />
* Describe community policy on testing and submitting patches/code, understand issue solving/triaging process.<br />
* Participate in a community which is open to code contributions.<br />
* Time a contribution within the project's release cycle.<br />
|}<br />
<br />
=== Pathway Steps, Outcomes, & Learning Activities ===<br />
<br />
Follow the project’s policies and practices to complete the steps below.<br />
<br />
{| {{Pathway Step Table}}<br />
| 1. Identify feature to be coded.<br />
: - explore tickets in feature tracker<br />
: - discuss with community<br />
| Feature identified.<br />
|<br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Critical Thinking|Crit Think]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Requirements_Analysis|Requirements analysis]]<br />
* TBD: identify feature to be implemented<br />
|-<br />
| 2. Claim the ticket for the feature.<br />
: - create ticket if necessary.<br />
| Ticket for feature is claimed.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
|-<br />
| 3. Implement feature.<br />
| Code to implement feature is complete.<br />
: - Possibly: Test cases for feature are complete.<br />
| <br />
* [[:Category:Problem Solving|Prob Solv]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
* [[:Category:Management|Mgmt]]<br />
|<br />
* [[Introduction_to_Test_Driven_Development| Intro to test driven development]]<br />
* [[Test_Driven_Development|Test driven development]]<br />
* [[Review_Coding_Conventions|Review coding conventions]]<br />
* [[Document_Code_with_Meaningful_Comments_(Activity)|Document code]]<br />
* [[Unit_Test_With_GoogleTest_Activity|Unit test]]<br />
* [[Examine_Branch_Test_Coverage_(Activity)|Examine branch test coverage]]<br />
|-<br />
| 4. Submit changes to community.<br />
| Code to implement the feature is accepted into the project’s codebase, or the feature is abandoned.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Git:_GitHub_Workflow_Activity|GitHub workflows]]<br />
* [[Git:_GitHub_Issues_and_Pull_Requests|GitHub issues and PRs]]<br />
|-<br />
| 5. Complete process to close ticket.<br />
| Ticket for feature is closed.<br />
| <br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
|}<br />
<br />
=== Notes for Learning Activities Related to this Pathway ===<br />
<br />
When creating activities:<br />
<br />
# Identify reasonable features to be implemented. This can reduce student time searching for issues, and reduce the chances of choosing a feature that is too difficult or too easy.<br />
<br />
[[Category:Pathways]]<br />
[[Category:Critical Thinking]]<br />
[[Category:Information Processing]]<br />
[[Category:Management]]<br />
[[Category:Problem Solving]]<br />
[[Category:Written Communication]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Category:Add_a_Feature_(Pathway)Category:Add a Feature (Pathway)2017-03-08T19:24:03Z<p>Cmurphy: /* Pathway Steps, Outcomes, & Learning Activities */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''The contributor will''': contribute code to implement a requested feature.<br />
'''The contribution is''': code accepted into the project's codebase to implement a requested feature.<br />
<br />
=== Prerequisites ===<br />
<br />
{| {{Pathway Prerequisite Table}}<br />
| Tools<br />
| <br />
* Code reasonably well in the languages required for the task.<br />
* Correctly use a command-line interface.<br />
* Correctly use the basics of version control including branching and merging.<br />
* Create a correct patch or pull request.<br />
|-<br />
| Software Configuration<br />
| <br />
* Download and install the development environment.<br />
* Run the program.<br />
|-<br />
| Issue Tracker<br />
|<br />
* Describe issue trackers and how they are used.<br />
* Access the issue tracker with appropriate permissions.<br />
* Read, create, and update issues in a tracker.<br />
|-<br />
| Community<br />
| <br />
* Contact community members for help and identify the person responsible for committing changes.<br />
* Describe community policy on testing and submitting patches/code, understand issue solving/triaging process.<br />
* Participate in a community which is open to code contributions.<br />
* Time a contribution within the project's release cycle.<br />
|}<br />
<br />
=== Pathway Steps, Outcomes, & Learning Activities ===<br />
<br />
Follow the project’s policies and practices to complete the steps below.<br />
<br />
{| {{Pathway Step Table}}<br />
| 1. Identify feature to be coded.<br />
: - explore tickets in feature tracker<br />
: - discuss with community<br />
| Feature identified.<br />
|<br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Critical Thinking|Crit Think]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Requirements_Analysis|Requirements analysis]]<br />
* TBD: identify feature to be implemented<br />
|-<br />
| 2. Claim the ticket for the feature.<br />
: - create ticket if necessary.<br />
| Ticket for feature is claimed.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
|-<br />
| 3. Implement feature.<br />
| Code to implement feature is complete.<br />
: - Possibly: Test cases for feature are complete.<br />
| <br />
* [[:Category:Problem Solving|Prob Solv]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
* [[:Category:Management|Mgmt]]<br />
|<br />
* [[Test_Driven_Development|Test driven development]]<br />
* [[Review_Coding_Conventions|Review coding conventions]]<br />
* [[Document_Code_with_Meaningful_Comments_(Activity)|Document code]]<br />
* [[Unit_Test_With_GoogleTest_Activity|Unit test]]<br />
* [[Examine_Branch_Test_Coverage_(Activity)|Examine branch test coverage]]<br />
|-<br />
| 4. Submit changes to community.<br />
| Code to implement the feature is accepted into the project’s codebase, or the feature is abandoned.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Git:_GitHub_Workflow_Activity|GitHub workflows]]<br />
* [[Git:_GitHub_Issues_and_Pull_Requests|GitHub issues and PRs]]<br />
|-<br />
| 5. Complete process to close ticket.<br />
| Ticket for feature is closed.<br />
| <br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
|}<br />
<br />
=== Notes for Learning Activities Related to this Pathway ===<br />
<br />
When creating activities:<br />
<br />
# Identify reasonable features to be implemented. This can reduce student time searching for issues, and reduce the chances of choosing a feature that is too difficult or too easy.<br />
<br />
[[Category:Pathways]]<br />
[[Category:Critical Thinking]]<br />
[[Category:Information Processing]]<br />
[[Category:Management]]<br />
[[Category:Problem Solving]]<br />
[[Category:Written Communication]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Category:Add_a_Feature_(Pathway)Category:Add a Feature (Pathway)2017-03-08T19:23:11Z<p>Cmurphy: /* Pathway Steps, Outcomes, & Learning Activities */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''The contributor will''': contribute code to implement a requested feature.<br />
'''The contribution is''': code accepted into the project's codebase to implement a requested feature.<br />
<br />
=== Prerequisites ===<br />
<br />
{| {{Pathway Prerequisite Table}}<br />
| Tools<br />
| <br />
* Code reasonably well in the languages required for the task.<br />
* Correctly use a command-line interface.<br />
* Correctly use the basics of version control including branching and merging.<br />
* Create a correct patch or pull request.<br />
|-<br />
| Software Configuration<br />
| <br />
* Download and install the development environment.<br />
* Run the program.<br />
|-<br />
| Issue Tracker<br />
|<br />
* Describe issue trackers and how they are used.<br />
* Access the issue tracker with appropriate permissions.<br />
* Read, create, and update issues in a tracker.<br />
|-<br />
| Community<br />
| <br />
* Contact community members for help and identify the person responsible for committing changes.<br />
* Describe community policy on testing and submitting patches/code, understand issue solving/triaging process.<br />
* Participate in a community which is open to code contributions.<br />
* Time a contribution within the project's release cycle.<br />
|}<br />
<br />
=== Pathway Steps, Outcomes, & Learning Activities ===<br />
<br />
Follow the project’s policies and practices to complete the steps below.<br />
<br />
{| {{Pathway Step Table}}<br />
| 1. Identify feature to be coded.<br />
: - explore tickets in feature tracker<br />
: - discuss with community<br />
| Feature identified.<br />
|<br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Critical Thinking|Crit Think]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Requirements_Analysis|Requirements analysis]]<br />
|-<br />
| 2. Claim the ticket for the feature.<br />
: - create ticket if necessary.<br />
| Ticket for feature is claimed.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
|-<br />
| 3. Implement feature.<br />
| Code to implement feature is complete.<br />
: - Possibly: Test cases for feature are complete.<br />
| <br />
* [[:Category:Problem Solving|Prob Solv]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
* [[:Category:Management|Mgmt]]<br />
|<br />
* [[Test_Driven_Development|Test driven development]]<br />
* [[Review_Coding_Conventions|Review coding conventions]]<br />
* [[Document_Code_with_Meaningful_Comments_(Activity)|Document code]]<br />
* [[Unit_Test_With_GoogleTest_Activity|Unit test]]<br />
* [[Examine_Branch_Test_Coverage_(Activity)|Examine branch test coverage]]<br />
|-<br />
| 4. Submit changes to community.<br />
| Code to implement the feature is accepted into the project’s codebase, or the feature is abandoned.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Git:_GitHub_Workflow_Activity|GitHub workflows]]<br />
* [[Git:_GitHub_Issues_and_Pull_Requests|GitHub issues and PRs]]<br />
|-<br />
| 5. Complete process to close ticket.<br />
| Ticket for feature is closed.<br />
| <br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
|}<br />
<br />
=== Notes for Learning Activities Related to this Pathway ===<br />
<br />
When creating activities:<br />
<br />
# Identify reasonable features to be implemented. This can reduce student time searching for issues, and reduce the chances of choosing a feature that is too difficult or too easy.<br />
<br />
[[Category:Pathways]]<br />
[[Category:Critical Thinking]]<br />
[[Category:Information Processing]]<br />
[[Category:Management]]<br />
[[Category:Problem Solving]]<br />
[[Category:Written Communication]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Category:Add_a_Feature_(Pathway)Category:Add a Feature (Pathway)2017-03-08T19:21:31Z<p>Cmurphy: /* Pathway Steps, Outcomes, & Learning Activities */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''The contributor will''': contribute code to implement a requested feature.<br />
'''The contribution is''': code accepted into the project's codebase to implement a requested feature.<br />
<br />
=== Prerequisites ===<br />
<br />
{| {{Pathway Prerequisite Table}}<br />
| Tools<br />
| <br />
* Code reasonably well in the languages required for the task.<br />
* Correctly use a command-line interface.<br />
* Correctly use the basics of version control including branching and merging.<br />
* Create a correct patch or pull request.<br />
|-<br />
| Software Configuration<br />
| <br />
* Download and install the development environment.<br />
* Run the program.<br />
|-<br />
| Issue Tracker<br />
|<br />
* Describe issue trackers and how they are used.<br />
* Access the issue tracker with appropriate permissions.<br />
* Read, create, and update issues in a tracker.<br />
|-<br />
| Community<br />
| <br />
* Contact community members for help and identify the person responsible for committing changes.<br />
* Describe community policy on testing and submitting patches/code, understand issue solving/triaging process.<br />
* Participate in a community which is open to code contributions.<br />
* Time a contribution within the project's release cycle.<br />
|}<br />
<br />
=== Pathway Steps, Outcomes, & Learning Activities ===<br />
<br />
Follow the project’s policies and practices to complete the steps below.<br />
<br />
{| {{Pathway Step Table}}<br />
| 1. Identify feature to be coded.<br />
: - explore tickets in feature tracker<br />
: - discuss with community<br />
| Feature identified.<br />
|<br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Critical Thinking|Crit Think]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
|-<br />
| 2. Claim the ticket for the feature.<br />
: - create ticket if necessary.<br />
| Ticket for feature is claimed.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
|-<br />
| 3. Implement feature.<br />
| Code to implement feature is complete.<br />
: - Possibly: Test cases for feature are complete.<br />
| <br />
* [[:Category:Problem Solving|Prob Solv]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
* [[:Category:Management|Mgmt]]<br />
|<br />
* [[Test_Driven_Development|Test driven development]]<br />
* [[Review_Coding_Conventions|Review coding conventions]]<br />
* [[Document_Code_with_Meaningful_Comments_(Activity)|Document code]]<br />
* [[Unit_Test_With_GoogleTest_Activity|Unit test]]<br />
* [[Examine_Branch_Test_Coverage_(Activity)|Examine branch test coverage]]<br />
|-<br />
| 4. Submit changes to community.<br />
| Code to implement the feature is accepted into the project’s codebase, or the feature is abandoned.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Git:_GitHub_Workflow_Activity|GitHub workflows]]<br />
* [[Git:_GitHub_Issues_and_Pull_Requests|GitHub issues and PRs]]<br />
|-<br />
| 5. Complete process to close ticket.<br />
| Ticket for feature is closed.<br />
| <br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
|}<br />
<br />
=== Notes for Learning Activities Related to this Pathway ===<br />
<br />
When creating activities:<br />
<br />
# Identify reasonable features to be implemented. This can reduce student time searching for issues, and reduce the chances of choosing a feature that is too difficult or too easy.<br />
<br />
[[Category:Pathways]]<br />
[[Category:Critical Thinking]]<br />
[[Category:Information Processing]]<br />
[[Category:Management]]<br />
[[Category:Problem Solving]]<br />
[[Category:Written Communication]]</div>Cmurphyhttp://www.foss2serve.org/index.php/Category:Add_a_Feature_(Pathway)Category:Add a Feature (Pathway)2017-03-08T19:20:40Z<p>Cmurphy: /* Pathway Steps, Outcomes, & Learning Activities */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''The contributor will''': contribute code to implement a requested feature.<br />
'''The contribution is''': code accepted into the project's codebase to implement a requested feature.<br />
<br />
=== Prerequisites ===<br />
<br />
{| {{Pathway Prerequisite Table}}<br />
| Tools<br />
| <br />
* Code reasonably well in the languages required for the task.<br />
* Correctly use a command-line interface.<br />
* Correctly use the basics of version control including branching and merging.<br />
* Create a correct patch or pull request.<br />
|-<br />
| Software Configuration<br />
| <br />
* Download and install the development environment.<br />
* Run the program.<br />
|-<br />
| Issue Tracker<br />
|<br />
* Describe issue trackers and how they are used.<br />
* Access the issue tracker with appropriate permissions.<br />
* Read, create, and update issues in a tracker.<br />
|-<br />
| Community<br />
| <br />
* Contact community members for help and identify the person responsible for committing changes.<br />
* Describe community policy on testing and submitting patches/code, understand issue solving/triaging process.<br />
* Participate in a community which is open to code contributions.<br />
* Time a contribution within the project's release cycle.<br />
|}<br />
<br />
=== Pathway Steps, Outcomes, & Learning Activities ===<br />
<br />
Follow the project’s policies and practices to complete the steps below.<br />
<br />
{| {{Pathway Step Table}}<br />
| 1. Identify feature to be coded.<br />
: - explore tickets in feature tracker<br />
: - discuss with community<br />
| Feature identified.<br />
|<br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Critical Thinking|Crit Think]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
|-<br />
| 2. Claim the ticket for the feature.<br />
: - create ticket if necessary.<br />
| Ticket for feature is claimed.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
|-<br />
| 3. Implement feature.<br />
| Code to implement feature is complete.<br />
: - Possibly: Test cases for feature are complete.<br />
| <br />
* [[:Category:Problem Solving|Prob Solv]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
* [[:Category:Management|Mgmt]]<br />
|<br />
* [[Test_Driven_Development|Test driven development]]<br />
* [[Review_Coding_Conventions|Review coding conventions]]<br />
* [[Document_Code_with_Meaningful_Comments_(Activity)|Document code]]<br />
* [[Unit_Test_With_GoogleTest_Activity|Unit test]]<br />
* [[Examine_Branch_Test_Coverage_(Activity)|Examine branch test coverage]]<br />
|-<br />
| 4. Submit changes to community.<br />
| Code to implement the feature is accepted into the project’s codebase, or the feature is abandoned.<br />
| <br />
* [[:Category:Information Processing|Info Proc]]<br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
* [[Git:_GitHub_Issues_and_Pull_Requests|GitHub issues and PRs]]<br />
|-<br />
| 5. Complete process to close ticket.<br />
| Ticket for feature is closed.<br />
| <br />
* [[:Category:Written Communication|Writ Comm]]<br />
|<br />
|}<br />
<br />
=== Notes for Learning Activities Related to this Pathway ===<br />
<br />
When creating activities:<br />
<br />
# Identify reasonable features to be implemented. This can reduce student time searching for issues, and reduce the chances of choosing a feature that is too difficult or too easy.<br />
<br />
[[Category:Pathways]]<br />
[[Category:Critical Thinking]]<br />
[[Category:Information Processing]]<br />
[[Category:Management]]<br />
[[Category:Problem Solving]]<br />
[[Category:Written Communication]]</div>Cmurphy