User:Dinclezan
Name: Daniela Inclezan
Position: Assistant Professor, Computer Science and Software Engineering, Miami University, 501 E High St, Oxford, OH 45056
email: inclezd@miamioh.edu
Page: http://miamioh.edu/cec/academics/departments/cse/about/faculty-and-staff/inclezan_daniela/index.html
GitHub:
IRC: server: nick: channels:
HFOSS Projects:
HFOSS-Related Courses:
Grants:
Publications:
Other Organizations:
Bio: I am involved with the Humanitarian Engineering and Computing (HE&C) minor at Miami University and serve as the advisor for the Computer Science students enrolled in this the minor. I am also the faculty advisor of the local chapter of the Girls Who Code club. I am interested in the HFOSS initiative as a way to recruit and retain minority students and provide learning opportunities for students in the HE&C minor.
Stage 1A. Intro to FOSS Project -- Notes
SUGAR LABS
- Contributions
- Roles most applicable to my students:
- Developer
- writing and testing code, reporting bugs
- Designer
- user interface design, web design, mock-ups design -- suitable for my students majoring in Software Engineering
- Commonalities across roles: Focus on communication and education.
- Differences between roles: Different skillsets are required.
- Roles most applicable to my students:
- Tracker
- Submitting a bug: Find the relevant activity or repo component; go to the issues tab; press the green button to submit a bug.
- Types of tickets: defect, enhancement, task
- Information available for each ticket: ticket (number), summary (description), status (new, assigned, reopened, accepted, closed), owner, type, priority(unspecified, normal, high, low), milestone
- Repository
- Date of last commit: March 13, 2019
- Release Cycle:
- Relationship between the release cycle and roadmap update: The roadmap is updated at the beginning of each release cycle. The roadmap may include
- the schedule of release dates and freeze points; the list of modules and external dependencies; references to tickets considered for the release; references to new feature proposals.
SAHANA EDEN
- Community
- Commonalities between contributor groups: Most of the roles are rather on the technical side. The only exceptions are the tester and translator roles.
- Differences between contributor groups: technical vs. non-technical contributor; required expertise (e.g., GIS, sys admin, etc.); amount of details, guidelines and training provided
- Differences in structure compared to the Sugar Labs website: The technical roles are more in number and divided into separate categories (developers, designers, Sys Admins, GIS specialists); generally more guidelines and instructions; a higher level of technical expertise seems to be required at first glance.
- Tracker
- Differences with respect to the Sugar Labs tracker page:
- Preset labels can be selected from a dropdown menu
- Labels are not grouped by type of information in the list of labels to choose from (e.g., priority labels, type of issue labels and component information are all mixed together in the same list), but they are color-coded
- The date when the issue was open is recorded
- Comments are available
- Types of issues: bug, enhancement, documentation
- Differences with respect to the Sugar Labs tracker page:
- Repository
- Date of last commit: April 26, 2019
- Release Cycle: Unable to access the page (ERROR: FORBIDDEN)
Stage 1B.1 FOSS Field Trip -- Notes
Part 1. GitHub
- (2.1) How many repositories are found for "education"? 27,839
- (2.2) How many of these repos use the JavaScript language? 3,456
- (2.3) In the first page of results, which repo was updated most vs least recently? nodeschool/los-angeles vs drongous/ems
- (3.1) Which education repo has the most stars? How many? freeCodeCamp - 303k
- (5.1) How many issues are open? closed? 228 Open; 13,336 Closed
- (5.2) How many pull requests are open? closed? 1,781 Open; 20,332 Closed
- (5.3) Click on the Insights tab. What do you see? An overview and graph for the most recent pull requests and issues (default: last week)
- (5.4) Within Insights, go to the left menu and click on Commits. What do you see? A chart with the number of commits per week. The most commits were done in early October 2018.
- (6.1) Search for "humanitarian" projects. How many repos are found? 507
- (6.2) Find HTBox/crisischeckin. How many stars does it have? What language(s) does it use? When was the last update? 178 stars; C#; Oct 24, 2018
- (6.3) Search for "disaster management", or terms that interest you. How many repos are found? disaster management - 473; language preservation - 18
Part 2. OpenHub
- (2.1) Search for "education." The listing shows the number of pages, not the number of projects. By default, each page shows 10 projects. How many projects were found?2,262
- (3.1) Which (if any) of the most active projects do you recognize? Sakai (11th most active)
- (4.1) From the KDE Education page, click on Code Locations (on the right side). Are any of the repo locations on GitHub? No (does not seem so based on the repository URLs)
- (4.2) Go back to KDE Education, and click on Similar Projects (below Code Locations). How many similar projects are listed? 10
- (4.3) This page contains general information for the similar projects. What info is shown for each? Name, activity level, language, license, and icon
- (5.1) How many projects did the search for "humanitarian"/ "disaster management"/ desired term return? humanitarian - 23; disaster management - 30; language preservation - 16
- (6) Why is "activity not available"? Because of problems with the projects' code locations or other problems blocking Open Hub from collecting and analyzing code
- (7.1) Organizations: What info is shown? Most active orgs, newest orgs, orgs by 30 day commit volume, stats by sector
- (8.1) In Organizations, search for "OpenMRS". Do the search results show projects or organizations? organizations
- (8.2) Find the project "OpenMRS Core". When was the last commit? Hard to find: February 2018?
- (9) Search for "OpenMRS Core" in GitHub. When was the last commit? On May 20, 2019 (9 hours ago).
- (9.1) Why do you think these sites have different info? Because the project was transferred from OpenHub to GitHub? Or because OpenHub requires more information to analyze in order to show a project as active
- (10) What are some benefits & drawbacks of searching for a project in both GitHub & OpenHub? Benefits: they complement each other (e.g., info about last commit was easier to find in GitHub; can search by organization in OpenHub). Drawbacks: the information is organized and presented differently on the two platforms and you have to learn both.
Stage 1B.2 Project Evaluation -- Notes
Evaluation Factor | Level (0-2) |
Evaluation Data |
---|---|---|
Licensing | 2 | Mozilla Public License 2.0 (MPL-2.0) - open source (OSI) and free software (FSF) license |
Language | 2 | Java (96.2%); SQLPL (2.9%); Other (0.9%) |
Level of Activity | 2 | But: last quarter was not that active and there were few commits most weeks (under 5) |
Number of Contributors | 2 | 323 |
Product Size | 1 | 223.35 MB |
Issue Tracker | 2 | Ready for work: 1276; Closed: 14148; Third issue created on 2008-05-21, updated on 2019-04-08; Other issues created in 2014, 2017 and updated in 2019 |
New Contributor | 2 |
|
Community Norms | 2 | Code of Conduct:
(1) There is a section about consequences of breaking the code; (2) There is a section about people leaving the project and what they should do in this case; (3) Respect and consensus are discussed. Communications: (1) Contributors generally acknowledge others' good ideas and are thankful when helped; (2) Discussions usually start with a more formal language and then they move to informal language, especially between long-term collaborators; (3) Clarifications are demanded and offered using a polite tone. |
User Base | 2 |
|
Total Score | 17 |
Stage 1B.3 Intro to Copyright and Licensing -- Notes
- Project Licenses:
- https://github.com/openmrs/openmrs-core: Mozilla Public License, version 2.0
- https://github.com/apache/incubator-fineract: Apache License, Version 2.0, January 2004
- https://github.com/regulately/regulately-back-end: No license
- License "cans", "cannots", and "musts":
- Mozilla Public License, version 2.0:
- "Cans": commercial use, modify, distribute, sublicense, place warranty, use patent claims
- "Cannots": use trademark, hold liable
- "Musts": include copyright, include license, disclose source, include original
- Apache License, version 2.0:
- "Cans": commercial use, modify, distribute, sublicense, private use, use patent claims, place warranty
- "Cannots": hold liable, use trademark
- "Musts": include copyright, include license, state changes, include notice
- Mozilla Public License, version 2.0:
- Consider contributing:
- Mozilla Public License, version 2.0: No. Does no include the possibility of private use
- Apache License, version 2.0: Yes.
Stage 1B.4 FOSS in Courses (1) -- Notes
- Capstone Project (CSE 448/449) - Valuable resources: (i) Independent Capstone Project Design; (ii) Teaching Open Source: Sept 2018 - April 2019
- Have students go through some of the POSSE activities:
- Intro to FOSS (1A.1) -- select three projects they may be interested in as a team (or I pre-select three projects for them to consider?!?)
- Intro to FOSS Project Anatomy (1A.6)
- FOSS Field Trip (1B.1) -- the parts that relate the the three selected projects
- Project Evaluation (1B.2) -- evaluate each of the three selected projects; choose one project that the team will actually work on
- Contribute (in this order; decide a minimum of contributions accepted by the community for each grade level):
- Documentation (software engineering majors especially)
- Clean up tickets
- Add a test suite
- Propose UX design improvements (software engineering majors especially)
- Comment code that is unclear/ not well commented (?)
- Fix bugs
- Have students go through some of the POSSE activities:
- Comparative Programming Languages (CSE 465)
- Technology, Ethics, and Global Society (CSE 262)
Stage 1C.1 Intro to Bug Trackers -- Notes
(2) Projects: gtk, rhythmbox, vala, gnote, gnome, glib, pygobject, gimp, etc.
(3) Other info available: short description (title), when the ticket was open and by whom, when it was last updated, its type (e.g., bug, feature).
(4) Labels: type (e.g., bug, feature), project it relates to, what device is affected (e.g., webcam), OS (MacOS, Windows), what version is affected (e.g., GIMP 2.10.10), what is needed (e.g., needs information, needs design).
(5) Additional info when browsing through a couple of issues: activity (updates: added when and by whom), milestone, time tracking (i.e., estimate or time spent), due date, confidentiality, whether locked or not, status, asignee
(6) Other label groups: 2.blue (issues that require more discussion/design/info), 3.yellow (tickets that are non-issues, not really a problem), 4.purple (tasks that are good for newcomers), 8.green (documentation), 9.red (issues related to how users perceive the application), no_number.bluish_green (short/long term vision in terms of releases).
(7) How are issues organized on the board: open vs. closed issues, stretch (long term - 4 releases away) and deliverable (short term - 2 releases away).
(8) How does GNOME appear to use milestones? Collect issues for an upcoming release (See milestone "2.61.5 - Project Milestone" on page 1 with 0 issues as of 06/12/2019)
(9) Merge requests: In contrast with issues, merge request contain info on the pipeline: whether they passed, failed, or are running; and number of upvotes. Syntax for linking a merge request to an issue: "Request to merge [...] into [branch]"
Stage 1C.3 FOSS in Courses (2) -- Notes
Activity 1: Weekly reports My goal for this activity is to have a template for monitoring student work during a capstone project (i.e., contributions in terms of documentation, cleaned up tickets, test suites added, proposed UX design improvements, code comments, and bug fixes). It assumes that teams of 3-4 students have already went through several existent POSSE activities (see "Stage 1B.4 FOSS in Courses (1) -- Notes" above) and have selected a common project to work on. Students will be graded on their achievements on an individual basis, but will provide support and peer evaluations within the teams.
Instructions for the students: Fill out the form below with your answers to the following questions:
1. What area of contributions will you address? You should have made at least 2 contributions of a previous type before you move on to the next type of contributions.
2. Browse through the project to identify possible contributions that you can make. What areas of the project may be suitable for such contributions? List them. If you cannot identify such areas by yourself, contact the project community to inquire about it. Be ready to show the conversation to the project mentor faculty at the next meeting. You can ask for help in finding a suitable area of the project for contributions from your team mates. Report on how you identified for areas for contributions.
3. While browsing through the project, have you found any other parts of the project that may be suitable for types of contributions that you will address in the future?
Form: Name: __________________ Date: __________________
Focusing on Contributions of Type: (Check one) __ Documentation __ Cleaning up Tickets __ Adding Test Suites __ Proposing UX design improvements __ Writing Code Comments __ Fixing Bugs
Identified areas of the project that are suitable for contributions of this type: _____________________
Suitable areas identified by: (Check one or more) __ Investigating the project on my own __ Asking for help from the HFOSS project community __ Asking for help from other team members
Areas identified for other types of contributions: ________________ for contributions of type _____________________ (add several rows if needed)
Fill out the following table:
Learning Outcomes: After successfully completing this activity, the learner should be able to:
Prerequisite knowledge:
Estimated time required for instructor prep:
Estimated time for student completion:
The activity can be covered independent of the HFOSS community schedule.
Possible input required from the HFOSS community: What areas of the project may provide opportunities for the types of contributions listed above?
Contribution of the activity back to the HFOSS project: The activity is meant to be reused by other professors using HFOSS projects in teaching capstone design courses. The activity is supposed to be useful in that it provides a template for monitoring student work with minimal prep time for the instructor.
Assessment/grading: Each student will report their contributions individually, for each type of contribution (e.g., documentation, bug fixes), in terms of committed vs. accepted contributions by the HFOSS community. The other team members will provide support in finding places in the project that may allow for such contributions, but students will make their contributions individually. A minimum number of submitted and accepted contributions of each type will be decided upon by the instructor for each letter grade, with input from the POSSE community.
Questions or concerns: What projects are suitable for a capstone project, and especially for the types of contributions listed above? How many contributions of each type can reasonably be expected from each student?
Stumbling blocks or barriers to carrying out the activity/task:
Activity 2
This is suppose to help students reflect on their experience in the HFOSS capstone project.