Project Evaluation (Activity)

From Foss2Serve
(Difference between revisions)
Jump to: navigation, search
(→New contributor)
 
(10 intermediate revisions by 2 users not shown)
Line 29: Line 29:
  
 
=== Directions ===
 
=== Directions ===
−
 
+
=== Walk through of an evaluation of the OpenMRS project ===
−
==== Walk through of an evaluation of the OpenMRS project ====
+
  
 
To choose a FOSS project for yourself or your class, it helps to consider multiple criteria, which are explored below.
 
To choose a FOSS project for yourself or your class, it helps to consider multiple criteria, which are explored below.
Line 42: Line 41:
 
[[File:ProjEval-Img1.jpg|600px|thumb|center]]  
 
[[File:ProjEval-Img1.jpg|600px|thumb|center]]  
  
−
'''Licensing''' - A FOSS license allows anyone to use, change, and redistribute the software.  
+
==== Licensing ====
−
However, there are many FOSS licenses, and multiple views on what they should be.
+
A FOSS license allows anyone to use, change, and redistribute the software. However, there are many FOSS licenses.
 
The [https://opensource.org Open Source Initiative (OSI)] lists ''open source licenses'' at https://opensource.org/licenses/alphabetical.
 
The [https://opensource.org Open Source Initiative (OSI)] lists ''open source licenses'' at https://opensource.org/licenses/alphabetical.
 
The [https://fsf.org Free Software Foundation (FSF)] lists ''free software licenses'' at https://www.gnu.org/licenses/license-list.html.
 
The [https://fsf.org Free Software Foundation (FSF)] lists ''free software licenses'' at https://www.gnu.org/licenses/license-list.html.
 
In general, the OSI definition is broader, and so that list is longer.
 
In general, the OSI definition is broader, and so that list is longer.
 +
# On the repository page (see image above), click on the "<> Code" tab below the repository name.
 +
# Look below the tabs for a license name or a link to the license.
 +
# If the license is not shown, or the project is not on GitHub, look for a license file in the top level files of the repository.
 +
# Does the project use a license approved by the OSI? In the rubric, record your findings. {{Answer|Yes, Mozilla Public 2.0.}}
  
−
# On the repository page (see image above), click on the "<> Code" tab below the repository name.  Look below the tabs for a license name or link to the license. If the license is not shown, or the project is not on GitHub, look for a license file in the top level files of the repository.
+
==== Language ====
−
# Does OpenMRS use a license approved by the OSI? Enter your findings in the rubric. {{Answer|Yes.}}
+
If you, your team, and your students are already familiar (or expert) with the project's language(s),
−
 
+
−
'''Language''' - If you are your students are already familiar (or experts) with the language(s) used by the project,
+
 
it will be much easier to learn how the project works and make contributions.
 
it will be much easier to learn how the project works and make contributions.
−
# Click on the language details bar (see image above). Record the top three languages used and the percentage for each. {{Answer|96% Java, 3% SQL, 1% other (as of 2019-01)}}
+
# On the "<> Code" tab, click on the language details bar (see image above).  
−
 
+
# In the rubric, record the top three languages used and the percentages. {{Answer|96% Java, 3% SQL, 1% other (as of 2019-01)}}
−
'''Activity''' - To support student participation, a project should be reasonably active. Number of commits can be used as an indicator of activity. Little to no activity over a year, for example, may indicate that the project is dead, or mature and not being actively developed.
+
−
* Click the "Insights" tab then select "Commits"
+
−
* If we define "Active" as meaning that a majority of the weeks in a given quarter have commits, determine whether each quarter was active over the last year and place your findings in the rubric. Note: since the definition of "active" is approximate, assess each quarter at a glance rather than by actual count of commits.
+
  
−
'''Number of contributors''' - A common fossism states that "It's all about community," so a suitable project should have an active user community.  The community members are great resources for both faculty and students as they begin to learn about a new project, its culture, and norms.  
+
==== Activity ====
−
* Click the "< > Code" tab. The number of contributors is listed above the language details bar. Determine how many contributors there are to the OpenMRS core project and enter your findings in the rubric.
+
A project with little or no activity in the last year might be abandoned and dead,
 +
or it might be stable, mature, and not actively developed.
 +
One measure of activity is the number of ''commits'' (changes) made to the code.
 +
# Click on the "Insights" tab, and then click on "Commits" on the left menu.
 +
# The graph shows the number of commits in each week of the last year.  
 +
# Define a quarter (3 months) to be "active" if there were commits in a majority (over half) of the weeks in that quarter.
 +
# Decide (at a glance, no need to count) how many quarters were active, and record in the rubric.
  
−
'''Size''' - The size of the project is likely to be a factor depending on the level of your students.  A large project that is built using many various technologies is likely to seem overwhelming to a CS2 student, for example, but may be a perfect fit for a senior capstone course.  A simple first step is to determine how large the project is, additional research could be done to ascertain complexity. By default, Github does not provide information about how many lines of code there are in a repository or its size.  You can however install an extension for Google Chrome that will display the size. Follow the instructions below to install the extension.
+
==== Number of contributors ====
 +
A FOSSism states that "It's all about community" - a healthy project usually has an active user community.
 +
The community is a great resource to help newcomers learn about the project, its culture, and norms.
 +
# Click on the "<> Code" tab.   
 +
# The number of contributors is listed above the language details bar. Record this in the rubric.
  
 +
==== Size ====
 +
A large project that uses many technologies might overwhelm a CS2 student, but be perfect for a senior capstone course.
 +
A simple measure of size is the lines of code (LoC), and you could do more research to explore complexity.
 +
By default, Github does not show the size or lines of code for a repository.
 +
However, you can install an extension for Google Chrome that will display the size. Follow the instructions below.
 
# Open Chrome and go to: https://chrome.google.com/webstore/search/github%20repository%20size
 
# Open Chrome and go to: https://chrome.google.com/webstore/search/github%20repository%20size
−
# Click the “Add to Chrome” button for the GitHub Repository Size extension
+
# Click the "Add to Chrome" button for the ''GitHub Repository Size'' extension
−
# Return to the GitHub page for OpenMRS. You should now see the repository size next to license type. Record the size in the rubric.  
+
# Return to the project page in GitHub. You should now see the repository size next to license type. Record the size in the rubric.  
  
−
'''Issue tracker''' - The issue tracker can provide insight into the health of a project.  An active issue tracker should highlight issues that clients/developers have logged as well as an indication that these issues are being addressed.  
+
==== Issue tracker ====
−
* Click "Issues" (note: this should appear next to "< > Code"; if you do not see this tab, then there are no issues logged in Github).  OpenMRS uses a third-party issue tracker - click the link to openmrs.org located near the top of the repository page, scroll to the bottom and click the "OpenMRS Issue Tracking" link. Scroll to the table labeled "Two Dimensional Filter Statistics: All JIRA Tickets" located near the bottom of the page. Provide answers to the following in the rubric.
+
An active issue tracker should highlight key issues that clients and developers have raised, and show that they are being addressed.
−
# How many open (for OpenMRS look at "ready for work") issues are there?  
+
# Click on the "Issues" tab, which should be next to "<> Code". (Note: If you do not see this tab, then no issues are logged in Github).   
−
# How many closed issues are there?
+
#* OpenMRS uses a separate issue tracker.
−
# When was the fifth issue opened (for OpenMRS look at the "ready for work" issues)?
+
## Click the link to openmrs.org located near the top of the repository page.
−
# Based on browsing the table, and clicking on some of the table cells, assess whether issues are actively being added and resolved  
+
## Scroll to the bottom and click the "OpenMRS Issue Tracking" link.
 +
## Scroll to the table labeled "Two Dimensional Filter Statistics: All JIRA Tickets" located near the bottom of the page.
 +
## Use this to answer the rubric questions below.
 +
# How many ''open'' ("ready for work") issues are there?  
 +
# How many ''closed'' issues are there?
 +
# Scroll to the top to see a list of ''Curated Introductory Tickets.'' When was the third issue opened?
 +
# Browse through other issues in the table, and click on some of the cells, to assess whether issues are actively being added and resolved. Record this in the rubric.
  
−
'''New contributor''' - The project should appear welcoming to new contributors. Some clear examples of this would be links to getting started pages or information on ways to become involved. These pages, in turn, should include additional detail about '''how''' to become involved, as well as information about '''how''' to connect with the community.
+
==== New contributor ====
−
* Browse the repository and associated links, is there any indication that the project welcomes new contributors? Indicate which of the following are present and provide links in the rubric. Note: for OpenMRS you will find that the link at the top to openmrs.org and the link toward the bottom of the repository page to the OpenMRS wiki quite useful!
+
A healthy project should welcome new contributors.
−
# Are there instructions for downloading and installing the development environment?
+
For example, there should be links to "getting started" pages and information on ways to get involved.
−
# Are communication mechanisms, such as IRC, list serves, you can join, meeting notices, etc. apparent?
+
These pages, in turn, should have more detail on '''how''' to become involved, and '''how''' to connect with the community.
−
# Is there a discussion platform? If so, how recent are the responses?
+
# Browse the GitHub repository and associated links. Are there signs that the project welcomes new contributors?  
−
# Is there Web presence? This might include information about the project, how to get started as a developer, links to blogs, links to IRC logs, links to pages that contain information about coding standards and the code submission process.
+
# Indicate which of the following are present and include links in the rubric.  
 +
#* Note: For OpenMRS you will find two links quite useful: one at the top to openmrs.org and one near the bottom to the OpenMRS wiki.
 +
## Are there instructions to download and install the development environment?
 +
## Are there communication mechanisms, such as IRC, listserves, meeting notices, etc. and instructions on how to access them?
 +
## Is there a discussion platform? If so, are there recent posts and responses?
 +
## Is there Web presence? This might include information about the project, how to get started as a developer, links to blogs, links to IRC logs, links to pages that contain information about coding standards and the code submission process.
 +
# Record your findings in the rubric.
  
−
'''Community norms''' - The way in which community members interact with one another is equally important, especially for student involvement. You do not want to point students to a project that advocates or permits lewd and unprofessional behavior.
+
==== Community norms ====
−
* Some projects provide a "Code of Conduct", yet others do not. It it quite possible that you will find the code of conduct more quickly by doing a Google search. For OpenMRS you should look in the "Developer Guide" (link along the left side in the OpenMRS wiki) and then choose "Conventions"
+
How community members interact with one another is important, especially for students.
−
* You should also review some actual communications to determine if there any indications of rude or inappropriate behavior. This could be quite time consuming since you would first have to determine the type of communication typically used by community members and then locate and review the appropriate artifacts. For OpenMRS, click the "TALK" link at the top of the OpenMRS wiki page and review the communications that occurred for two of the topics. Choose two that have at least 5 members and 15 or more replies.
+
You do not want to point students to a project that advocates or permits lewd and unprofessional behavior.
−
* Record the following in the rubric.
+
# Some projects have a "Code of Conduct", but others do not. Such codes are not in a standard location, so you might find it more quickly with a Google search.
−
# Provide three observations about the OpenMRS Code of Conduct.
+
#* For OpenMRS, look in the "Developer Guide" (link along the left side in the OpenMRS wiki) and then choose "Conventions".
−
# Provide three observations about the type of communication that occurred between community members on TALK. Is there any indication of rude or inappropriate behavior?
+
# Review some actual interactions for any rude or inappropriate behavior. This could be time consuming since you must first find the type of communication typically used by the community, and then find and review interactions. Choose two topics with at least 5 members and 15 or more replies.
 +
#* For OpenMRS, click the "TALK" link at the top of the OpenMRS wiki page.  
 +
# Record the following in the rubric.
 +
## Three observations about the project's Code of Conduct.
 +
## Three observations about communication that occur in the community. Is there any sign of rude or inappropriate behavior?
  
−
'''User base''' - A project will not thrive without a core user-base.  The user-base consists of clients, people who use the product on a day-to-day basis. They provide the development team with necessary feedback about the project, what works, what doesn't and what new features they might like to see. If no one is using the product then developers are likely to abandon it. Browse the repository and related links.
+
==== User base ====
−
* In the rubric record your answers to the following.
+
A project will not thrive without a core ''user base'' of clients who use the project on a day-to-day basis.
−
# Does there appear to be a user base?
+
They give the development team necessary feedback about the project, what works, what doesn't, and what new features they want.
−
# Are there instructions for downloading and setting up the software for use by clients?
+
If no one uses the project, then developers are more likely to abandon it.  
−
# Are there instructions for how to use the software?
+
# Browse the repository and related links, and record your answers to the following in the rubric.
 +
## Does there appear to be a user base?
 +
## Are there instructions for clients to download and set up the software?
 +
## Are there instructions for how to use the software?
  
 
=== Deliverables ===
 
=== Deliverables ===
  
−
POSSE Participants: On your user wiki page, create a section that contains the Project Evaluation rubric describing your evaluation of OpenMRS as a suitable project for your course.
+
POSSE Participants: On your user wiki page, create a section with the [http://foss2serve.org/index.php/Project_Evaluation_Rubric_(Activity) Project Evaluation Rubric] that describes your evaluation of OpenMRS as a suitable project for your course.
  
 
= Notes for Instructors =
 
= Notes for Instructors =
Line 106: Line 138:
 
=== Assessment ===
 
=== Assessment ===
  
−
* For a more introductory class, assessment can be based on simply answering the question included above for evaluating OpenMRS.  This generally requires nothing more than being able to point and click and record the correct information.  Students will get a simple view of evaluation in one context
+
* For a more introductory class, assessment can be based on simply answering the question included above to evaluate OpenMRS.  This generally requires nothing more than being able to point and click and record the correct information.  Students will get a simple view of evaluation in one context.
−
* For more advanced students, some possible extensions would include:
+
* For more advanced students, possible extensions include:
−
** Providing the activity as shown above, but having them do an evaluation for another HFOSS project, perhaps one not on GitHub
+
** Provide the activity as shown above, but have students evaluate another HFOSS project, perhaps one not on GitHub.
−
** Having students assess several HFOSS projects
+
** Have students assess (and compare) several HFOSS projects.
−
** Adding additional assessment questions that require interpretation or comparison of data for various criteria
+
** Add assessment questions that require interpretation or comparison of data for various criteria.
−
** This particular activity can be the basis for a larger discussion or reflection about the general problem of product evaluation, selection, and comparison.  Those issues are relevant whether the product is FOSS, proprietary, or developed in-house.
+
** This activity could lead to a larger discussion or reflection about the general problem of product evaluation, selection, and comparison.  Those issues are relevant whether the product is FOSS, commercial, or developed in-house.
 
** This activity could also prompt discussion of measurement problems including qualitative vs. quantitative measures, development of frameworks for evaluation, and weighting of criteria to reach an overall evaluation conclusion
 
** This activity could also prompt discussion of measurement problems including qualitative vs. quantitative measures, development of frameworks for evaluation, and weighting of criteria to reach an overall evaluation conclusion
  
 +
<!-- QUESTIONS:
 +
  Do we need this table, or should we refer to (or insert) the more polished rubric?
 +
  Should we create a template for the rubric, so it looks more consistent?
 +
-->
 
The table below provides an outline of a rubric reflecting the recommended evaluation criteria.
 
The table below provides an outline of a rubric reflecting the recommended evaluation criteria.
  
Line 165: Line 201:
 
=== Comments ===
 
=== Comments ===
  
−
* The criteria defined above are general, but the specific ways of evaluating each criterion will vary by project. OpenMRS provides a good example for evaluating each criterion for projects on GitHub.  Projects on other forges will require different approaches to evaluate many of the criteria.
+
* These criteria are general, but the specific ways to evaluate each one will vary by project and forge. OpenMRS provides a good example for evaluating each criterion for projects on GitHub.  Projects on other forges will require different approaches to evaluate many of the criteria.
−
* There tend to be similarities in the way HFOSS projects are structured. If you repeat this evaluation for a series of candidate projects, it gets easier to do the evaluation quickly.  The situation is similar to the time it takes to learn a first or second programming language vs a sixth or seventh programming language.  After doing a few, you know what to look for.
+
* FOSS projects tend to have similar structures. If you repeat this evaluation for several projects, it gets easier and quicker, since you know what to look for. (A bit like learning multiple programming languages.)
−
 
+
 
=== Variants and Adaptations ===
 
=== Variants and Adaptations ===
  

Latest revision as of 15:36, 14 April 2019


Title

Project Evaluation

Overview

This activity guides a person or team to evaluate a FOSS project and decide if they might want to contribute to it. This includes instructors who want to choose an HFOSS project for a course. This activity evaluates characteristics that include: pattern of contributions, pattern of commits, programming languages used, and more. This activity uses OpenMRS as a sample project to evaluate.

Prerequisites
  • Have Google Chrome installed.
  • Understanding of the course or context in which an HFOSS project will be used.
  • Completion of FOSS Field Trip (Activity) or an understanding of GitHub and OpenHub.
Learning
Objectives 		After successfully completing this activity, the learner should be able to:
  • Identify HFOSS projects that seem good for new contributors.
Process Skills
Practiced

Information Processing, Assessment


Background

Not all projects are equally good for a new contributor. Some projects are welcoming and provide clear pathways to join their community. Other projects are less welcoming, or not well organized to support new people. Thus, it is helpful to evaluate a project before getting involved and contributing. This is particularly important when a teacher selects a project for students, or when students select a project for assignments or a project. The criteria below provide a framework to consider, but are not foolproof.

Directions

Walk through of an evaluation of the OpenMRS project

To choose a FOSS project for yourself or your class, it helps to consider multiple criteria, which are explored below. The Project Evaluation Rubric has descriptions and instructions to score each criterion. Copy the Project Evaluation Rubric onto your wiki page. Include your findings (notes and the answers to the questions below) in your rubric, along with your scores for each.

This activity uses OpenMRS as an example to evaluate. Thus, go to the OpenMRS core repository (https://github.com/openmrs/openmrs-core).

ProjEval-Img1.jpg

Licensing

A FOSS license allows anyone to use, change, and redistribute the software. However, there are many FOSS licenses. The Open Source Initiative (OSI) lists open source licenses at https://opensource.org/licenses/alphabetical. The Free Software Foundation (FSF) lists free software licenses at https://www.gnu.org/licenses/license-list.html. In general, the OSI definition is broader, and so that list is longer.

  1. On the repository page (see image above), click on the "<> Code" tab below the repository name.
  2. Look below the tabs for a license name or a link to the license.
  3. If the license is not shown, or the project is not on GitHub, look for a license file in the top level files of the repository.
  4. Does the project use a license approved by the OSI? In the rubric, record your findings.

Language

If you, your team, and your students are already familiar (or expert) with the project's language(s), it will be much easier to learn how the project works and make contributions.

  1. On the "<> Code" tab, click on the language details bar (see image above).
  2. In the rubric, record the top three languages used and the percentages.

Activity

A project with little or no activity in the last year might be abandoned and dead, or it might be stable, mature, and not actively developed. One measure of activity is the number of commits (changes) made to the code.

  1. Click on the "Insights" tab, and then click on "Commits" on the left menu.
  2. The graph shows the number of commits in each week of the last year.
  3. Define a quarter (3 months) to be "active" if there were commits in a majority (over half) of the weeks in that quarter.
  4. Decide (at a glance, no need to count) how many quarters were active, and record in the rubric.

Number of contributors

A FOSSism states that "It's all about community" - a healthy project usually has an active user community. The community is a great resource to help newcomers learn about the project, its culture, and norms.

  1. Click on the "<> Code" tab.
  2. The number of contributors is listed above the language details bar. Record this in the rubric.

Size

A large project that uses many technologies might overwhelm a CS2 student, but be perfect for a senior capstone course. A simple measure of size is the lines of code (LoC), and you could do more research to explore complexity. By default, Github does not show the size or lines of code for a repository. However, you can install an extension for Google Chrome that will display the size. Follow the instructions below.

  1. Open Chrome and go to: https://chrome.google.com/webstore/search/github%20repository%20size
  2. Click the "Add to Chrome" button for the GitHub Repository Size extension
  3. Return to the project page in GitHub. You should now see the repository size next to license type. Record the size in the rubric.

Issue tracker

An active issue tracker should highlight key issues that clients and developers have raised, and show that they are being addressed.

  1. Click on the "Issues" tab, which should be next to "<> Code". (Note: If you do not see this tab, then no issues are logged in Github).
    • OpenMRS uses a separate issue tracker.
    1. Click the link to openmrs.org located near the top of the repository page.
    2. Scroll to the bottom and click the "OpenMRS Issue Tracking" link.
    3. Scroll to the table labeled "Two Dimensional Filter Statistics: All JIRA Tickets" located near the bottom of the page.
    4. Use this to answer the rubric questions below.
  2. How many open ("ready for work") issues are there?
  3. How many closed issues are there?
  4. Scroll to the top to see a list of Curated Introductory Tickets. When was the third issue opened?
  5. Browse through other issues in the table, and click on some of the cells, to assess whether issues are actively being added and resolved. Record this in the rubric.

New contributor

A healthy project should welcome new contributors. For example, there should be links to "getting started" pages and information on ways to get involved. These pages, in turn, should have more detail on how to become involved, and how to connect with the community.

  1. Browse the GitHub repository and associated links. Are there signs that the project welcomes new contributors?
  2. Indicate which of the following are present and include links in the rubric.
    • Note: For OpenMRS you will find two links quite useful: one at the top to openmrs.org and one near the bottom to the OpenMRS wiki.
    1. Are there instructions to download and install the development environment?
    2. Are there communication mechanisms, such as IRC, listserves, meeting notices, etc. and instructions on how to access them?
    3. Is there a discussion platform? If so, are there recent posts and responses?
    4. Is there Web presence? This might include information about the project, how to get started as a developer, links to blogs, links to IRC logs, links to pages that contain information about coding standards and the code submission process.
  3. Record your findings in the rubric.

Community norms

How community members interact with one another is important, especially for students. You do not want to point students to a project that advocates or permits lewd and unprofessional behavior.

  1. Some projects have a "Code of Conduct", but others do not. Such codes are not in a standard location, so you might find it more quickly with a Google search.
    • For OpenMRS, look in the "Developer Guide" (link along the left side in the OpenMRS wiki) and then choose "Conventions".
  2. Review some actual interactions for any rude or inappropriate behavior. This could be time consuming since you must first find the type of communication typically used by the community, and then find and review interactions. Choose two topics with at least 5 members and 15 or more replies.
    • For OpenMRS, click the "TALK" link at the top of the OpenMRS wiki page.
  3. Record the following in the rubric.
    1. Three observations about the project's Code of Conduct.
    2. Three observations about communication that occur in the community. Is there any sign of rude or inappropriate behavior?

User base

A project will not thrive without a core user base of clients who use the project on a day-to-day basis. They give the development team necessary feedback about the project, what works, what doesn't, and what new features they want. If no one uses the project, then developers are more likely to abandon it.

  1. Browse the repository and related links, and record your answers to the following in the rubric.
    1. Does there appear to be a user base?
    2. Are there instructions for clients to download and set up the software?
    3. Are there instructions for how to use the software?

Deliverables

POSSE Participants: On your user wiki page, create a section with the Project Evaluation Rubric that describes your evaluation of OpenMRS as a suitable project for your course.

Notes for Instructors

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.

Assessment

  • For a more introductory class, assessment can be based on simply answering the question included above to evaluate OpenMRS. This generally requires nothing more than being able to point and click and record the correct information. Students will get a simple view of evaluation in one context.
  • For more advanced students, possible extensions include:
    • Provide the activity as shown above, but have students evaluate another HFOSS project, perhaps one not on GitHub.
    • Have students assess (and compare) several HFOSS projects.
    • Add assessment questions that require interpretation or comparison of data for various criteria.
    • This activity could lead to a larger discussion or reflection about the general problem of product evaluation, selection, and comparison. Those issues are relevant whether the product is FOSS, commercial, or developed in-house.
    • This activity could also prompt discussion of measurement problems including qualitative vs. quantitative measures, development of frameworks for evaluation, and weighting of criteria to reach an overall evaluation conclusion

The table below provides an outline of a rubric reflecting the recommended evaluation criteria.

Evaluation Factor Level
(0-2) 		Evaluation Data
Licensing
Language
Level of Activity
Number of Contributors
Product Size
Issue Tracker
New Contributor
Community Norms
User Base
Total Score

Comments

  • These criteria are general, but the specific ways to evaluate each one will vary by project and forge. OpenMRS provides a good example for evaluating each criterion for projects on GitHub. Projects on other forges will require different approaches to evaluate many of the criteria.
  • FOSS projects tend to have similar structures. If you repeat this evaluation for several projects, it gets easier and quicker, since you know what to look for. (A bit like learning multiple programming languages.)

Variants and Adaptations

POGIL-style combined FOSS Field Trip and Project Evaluation used by Chris Murphy in his FOSS Course, UPenn, Murphy.

Additional Information

ACM BoK
Area & Unit(s)

SE/Software Project Management, SP/Professional Ethics, SP/Intellectual Property, SP/Professional Communication

ACM BoK
Topic(s)
  • Project Management
  • Exposure to the idea that a project has a code of conduct
  • Exposure to the idea that licensing of an open source project is essential
  • Professional communication and exposure to communication and collaboration tools
Difficulty

Easy

Estimated Time
to Complete

60-90 minutes

Environment /
Materials
Author(s)

Darci Burdge, Greg Hislop, Michele Purcell

Source
License

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License

CC license.png


Suggestions for Open Source Community

None at this time.

Retrieved from "http://foss2serve.org/index.php?title=Project_Evaluation_(Activity)&oldid=13221"
Personal tools
Namespaces
Variants
Actions
Events
Learning Resources
HFOSS Projects
Evaluation
Navigation
Toolbox