Updated Assessment #29
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -105,7 +105,7 @@ when creating python programs. | |
| * N = No written code or monolithic code | ||
| * I = Language constructs used inappropriately | ||
| * A = Some language constructs used appropriately | ||
| * G = Most language constructs used appropriately | ||
| * E = All language constructs used efficiently and reason is documented | ||
|
|
||
| ### Project Management with GitHub | ||
|
|
@@ -119,56 +119,57 @@ when creating python programs. | |
| * E = Issue is unique, well described, and a possible reason for occurrence | ||
| and solution is mentioned | ||
| * Using the GitHub flow model | ||
| * N = GitHub flow model unused or no commits made to the GitHub | ||
| * I = Pushed to master or made non-descriptive commits | ||
| * A = Pushed to correct repository with descriptive commits to the Github | ||
| repository | ||
| * G = Use of a branch/fork demonstrated appropriately | ||
| (e.g having a feature branch) along with descriptive commits | ||
| * E = Use of multiple useful branches/forks demonstrated appropriately | ||
| containing multiple consistent and descriptive commits | ||
|
There was a problem hiding this comment. Coherent and consistent do not mean the same thing -> is the change in meaning acceptable? I would argue that coherent commits are incredibly necessary. There was a problem hiding this comment. I no longer have the paper with me, but if I remember correctly this change was suggested by @gkapfham. |
||
| * Creating and using a repository branch | ||
| * N = Did not create or utilize branches | ||
| * I = Created unclear branches | ||
| * A = Created too many poorly named branches | ||
| * G = Created useful adequately named branches | ||
| * E = Created useful and descriptive branches | ||
| * Creating and using a repository fork | ||
| * N = Did not create or utilize forks | ||
| * I = Created unclear forks | ||
| * A = Created too many poorly named forks | ||
| * G = Created useful adequately named forks | ||
| * E = Created useful and descriptive forks | ||
| * Merging a branch or a fork to another branch or fork | ||
| * N = Not communicating changes before merging branches and forks | ||
| * I = Merging with minimal communication or merging defective code | ||
| * A = Communicating changes with the team and reconciling differences | ||
| * G = Merging branches after extensive communication | ||
| * E = Merging branches with well-documented, detailed code and | ||
| extensive team communication | ||
|
There was a problem hiding this comment. Communication is not necessarily in teams here... is there some justification for this change? |
||
| * Creating and reviewing a pull request | ||
| * N = No PR or Pull Request made | ||
| * I = Does not tag the related issues it is trying to close with poor description | ||
| * A = Tags any related issues it is trying to close, describes | ||
| proposed changes by a person | ||
| * G = Tags any related issues it is trying to close, describes most proposed changes, | ||
| and passes Travis CI | ||
|
There was a problem hiding this comment. This is about creating and reviewing the PR, not creating code that passes Travis CI. The old wording was inadequate, but the new wording doesn't seem better. |
||
| * E = Tags any related issues it is trying to close, fully describes all | ||
| proposed changes and passes Travis CI | ||
| * Using appropriate commit messages | ||
| * N = Commit messages do not make sense | ||
| * I = Commit messages are uninformative | ||
| * A = Commit messages are sensible but not descriptive | ||
| * G = Commit messages are clear, concise and moderately descriptive | ||
|
There was a problem hiding this comment. The addition of concise here, in my opinion, makes the difference between level |
||
| * E = Commit messages are clear, concise, and descriptive | ||
|
|
||
| ### Continuous Integration with Travis | ||
|
|
||
| * Setup and configure Travis CI | ||
| * N = Fails to perform any setup and configuration of Travis CI | ||
| * I = Sets up and configures Travis CI which performs no checks | ||
| * A = Sets up and configures Travis CI that performs checks on less | ||
|
There was a problem hiding this comment. Wait.... this inverts the meaning of the sentence, and seems that setting up checks on less relevant project deliverables is not as desirable? This is not clear. |
||
| relevant project deliverables | ||
| * G = Sets up and configures Travis CI to perform checks on the most relevant | ||
| project deliverables | ||
| * E = Correctly sets up and configures Travis CI to perform relevant | ||
| checks for all project deliverables | ||
|
|
@@ -180,12 +181,12 @@ when creating python programs. | |
| * G = Performs a release through Travis CI with signed commits | ||
| * E = Performs a release through Travis CI with signed commits | ||
| and signed deliverables (e.g md5 hash) | ||
| * Create third-party integrations with Travis CI (e.g., [codecov](codecov.io)) | ||
| * N = No incorporation of third party integrations | ||
| * I = Third-party integrations were only partially implemented | ||
| * A = A few third-party integrations were implemented | ||
| * G = Most third-party integrations were implemented | ||
| * E = Many useful and relevant third-party integrations were implemented | ||
| * Add README badges that show status of Travis CI builds | ||
| * N = No addition of badges to the README | ||
| * I = Badge added for Travis CI builds but does not work | ||
|
|
@@ -202,31 +203,33 @@ when creating python programs. | |
| * A = A few status badges are in the README but are not in an | ||
| appropriate location | ||
| * G = Most relevant status badges are in the README and well located | ||
| * E = All relevant and many useful status badges are in the README and well | ||
| located | ||
|
|
||
| ### Foundations of Software Engineering | ||
|
|
||
| * Requirements engineering | ||
| * N = No effort to document, define, or maintain requirements present is | ||
| evident | ||
|
There was a problem hiding this comment.
|
||
| * I = Brief or unspecific documentation, definition, and maintenance given | ||
| * A = Explains what requirements have been specified in enough detail | ||
| to convey the most important information | ||
| * G = Documentation and definitions are well written giving other team members | ||
| an informed idea of the process | ||
| * E = Displayed highly detailed, elaborate, and complete | ||
| documentation, definition, and maintenance in the given design process | ||
| * Software architecture | ||
| * N = There is no consideration to the structure or organization of the project | ||
| * I = There are small amounts of structure to the system | ||
| * A = There is a incomplete blueprint for the software system | ||
| * G = There is a completed blueprint for the software system | ||
| * E = There is a completed detailed blueprint for all elements of the software | ||
| system including detailed documentation | ||
| * Software design | ||
| * N = No attempt to create a design | ||
| * I = Initial steps are taken to conceptualize, frame, and implement systems | ||
| * A = Some software design is visible to the point where a software solution | ||
Michionlion marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| looks to be developed soon | ||
| * G = A software solution is created that includes both an algorithm design and | ||
| a high-level architecture design | ||
| * E = All goals and expectations of the design are met and compatibility, reliability, | ||
|
|
||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This repeats the word repository unnecessarily, and should be reworded. There shouldn't be a need to append
to the repositoryon the end of each of these sentences.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it look better now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The line that was the problem is line 124 and 125 -- however this change is good as well!