{"id":17169242,"url":"https://github.com/samcrow/cook-e-process","last_synced_at":"2026-01-27T12:36:32.641Z","repository":{"id":146885858,"uuid":"49530614","full_name":"samcrow/Cook-E-Process","owner":"samcrow","description":"Process description for the Clock-E development team","archived":false,"fork":false,"pushed_at":"2016-01-20T00:38:03.000Z","size":151,"stargazers_count":0,"open_issues_count":0,"forks_count":1,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-05-31T03:29:45.212Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"TeX","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/samcrow.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2016-01-12T21:39:57.000Z","updated_at":"2016-01-19T20:31:42.000Z","dependencies_parsed_at":"2023-04-18T11:57:08.634Z","dependency_job_id":null,"html_url":"https://github.com/samcrow/Cook-E-Process","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/samcrow/Cook-E-Process","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/samcrow%2FCook-E-Process","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/samcrow%2FCook-E-Process/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/samcrow%2FCook-E-Process/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/samcrow%2FCook-E-Process/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/samcrow","download_url":"https://codeload.github.com/samcrow/Cook-E-Process/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/samcrow%2FCook-E-Process/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28813215,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-27T12:25:15.069Z","status":"ssl_error","status_checked_at":"2026-01-27T12:25:05.297Z","response_time":168,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-14T23:25:30.784Z","updated_at":"2026-01-27T12:36:32.621Z","avatar_url":"https://github.com/samcrow.png","language":"TeX","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Cook-E development team process #\n\n## Software toolset ##\n\n### Mobile application ###\n\nThe mobile application will be written in Java and will run on Android. It will support Android versions 4.0 and higher\n(API levels 14 and higher). According to Google's statistics, this will make the application compatible with 96% of\nAndroid devices that have recently provided their information to Google.\n\nThe development team chose to target Android because it is widely used and some team members have experience developing\nAndroid applications. Java is the primary language used for Android development, and all team members have experience with\nit.\n\n### Version control ###\n\nThe project will use Git for version control, with central repositories hosted using on github.com.\n\nThe project will use the issue tracking and wiki features of the GitHub repository for bug tracking and development documentation.\n\nThe project will use [Circle CI](https://circleci.com/) for continuous integration and automated test running. This website offers basic services free of charge and supports compiling Android applications.\n\n### Testing ###\n\nAll software components should be accompanied by unit tests developed in parallel.\nEach team member should write tests for their code.\nThe testing coordinator (see below) will develop integration tests and user interface tests for the application.\n\n### Code Style ###\n\nCode in the project should follow the [Android code style rules](https://source.android.com/source/code-style.html),\nwith the following exceptions:\n\n* In \"Follow Field Naming Conventions\", names of non-final fields may start with any letter\n* For positioning of curly braces, [Stroustrup style](https://en.wikipedia.org/wiki/Indent_style#Variant:_Stroustrup)\nis acceptable. This means that an `else` keyword may appear on the line after\nthe closing curly brace that precedes it.\n\n\n        // OK (Stroustrup style)\n        if (...) {\n            ...\n        }\n        else {\n            ...\n        }\n\n        // OK (Java style)\n        if (...) {\n            ...\n        } else {\n            ...\n        }\n\n## Licensing ##\n\nThe project will be licensed under the GNU General Public License, version 3. This license prevents use of the project code in closed-source software.\n\n## Group Dynamics ##\n\n### Core Roles ###\n\nSome team members have core roles that give them particular responsibilities in the project.\nAll team members will still work on developing the application.\n\n#### Project Manager: Xianzhe Peng ####\n\nThe responsibilities of the project manager include:\n\n* Leading team meetings\n* Resolving disputes (see Dispute Resolution below)\n* Updating the System Requirements Specification and System Design Specification and Plan\nfor later deliverables\n\n#### Testing Coordinator: Zijin Zhang ####\n\nThe responsibilities of the testing coordinator include:\n\n* Helping other team members set up unit testing for their code\n* Writing integration and user interface tests\n* Handling regressions, either by making fixes for small problems or opening\nissues and alerting the responsible team members for larger problems\n\n#### Infrastructure Coordinator: Sam Crow ####\n\nThe responsibilities of the infrastructure coordinator include:\n\n* Maintaining the repository and continuous integration system\n* Helping other team members use the version control system\n* Checking pull requests\n    * Confirming that new code passes tests and follows the code style guidelines\n    * Merging code from pull requests\n* Maintaining development documentation\n\n#### User Documentation Coordinator: Carson Lipscomb ####\n\nThe responsibilities of the user documentation coordinator include:\n\n* Defining the structure of user documentation\n* Ensuring that user documentation is consistent and of sufficient quality\n* Before each release, checking that all user documentation is accurate\n\n### Dispute Resolution ###\n\n#### Features ####\n\nAfter the core features in the software requirements are finalized, no feature\nmay be added to the project unless five of the seven team members vote in favor\nof adding it.\n\nAt any time, the project manager may decide to remove a feature to ensure that\nthe project is completed on time.\n\n#### Other Disputes ####\n\nIf a dispute cannot be resolved through deliberation, the project manager should\nmake an executive decision to resolve the dispute. The decision may be overridden\nif five or more of the seven team members vote to override it.\n\n### Justification ###\n\nThis system of roles ensures that important tasks are performed but does not\nrestrict the development tasks that team members can work on. The feature dispute\nresolution process is designed to reduce the risk of feature creep. The resolution\nprocess for other disputes is designed to be fast while still allowing the team\nto override project manager decisions in unusual circumstances.\n\n## Timeline ##\n\n* 2016-01-22: Software requirements specification due\n* 9 days: Team splits into user interface design, algorithms, and application groups\n    * 3 days: user interface design group develops detailed user interface design,\n    other groups design data and algorithms\n    * 6 days: Application group starts implementing user interface, other groups\n    finish data and algorithm design\n* 2016-02-01: Software design specification due\n* 6 days: Prepare zero-feature release\n    * 2016-02-02: Infrastructure coordinator creates project\n    * Application group implements user interface\n    * Other team members, led by the infrastructure coordinator and the user\n    documentation coordinator, write initial documentation\n* 2016-02-08: Zero-feature release due, algorithm design must be complete\n* 11 days: Implement features\n* 2016-02-19: Beta release due\n* 6 days: Prepare for feature-complete release\n    * 2016-02-20: Testing coordinator identifies deficiencies in tests and asks\n    the responsible team members to improve them, user documentation coordinator\n    identifies user documentation deficiencies and arranges for them to be fixed\n    * 2016-02-25: Testing coordinator runs coverage tool and records results\n* 2016-02-26: Feature-complete release due\n* 6 days: Prepare for release candidate\n    * 2016-02-27: One team member does code review, first user test\n    * 2016-02-29: Fix issues from first user test\n    * 2016-03-01: Second user test\n    * 2016-03-02: Fix issues from second user test\n    * 2016-03-03: Third user test, fix issues from third user test\n* 2016-03-04: Release candidate due\n* 3 days: Team splits into fix group and deliverable group\n    * Fix group identifies issues to fix and fixes them\n    * Deliverable group prepares deliverables for the final release\n* 2016-03-08: Final release due\n\n## Risk Summary ##\n\n### Scheduling Algorithm ###\n\nThe scheduling algorithm is the most critical part of this project. It needs to\nsolve a problem with many constraints. The most difficult part of the algorithm is being able to adjust to users' varying times at completing different steps. If users do not perceive that the\nalgorithm is better at scheduling than a person, they will not use the application.\n\nTo improve the probability of the team developing a good algorithm, we have allocated a long period of time\nearly in the project for algorithm design. Part of the team will work primarily\non the algorithm.\n\n### Acquiring Recipe Data ###\n\nA key part of this project is acquiring enough recipes to be useful for a user who may want to cook any combination of dishes. There may be difficulty in finding data sources for the recipes and then creating an automated way to pull that data and putting it into our own database (or streaming it from the source).\n\nFor the early prototypes we will manually add around 10 recipes and then spend time adding recipes to the database after the scheduling algorithm is finished\n\n### Testing Difficulties ###\n\nTesting the whole application and its user interface will be more complex than\nsmall-scale unit testing. The testing coordinator will be responsible for\nsetting up and maintaining user interface tests. If automated user interface\ntesting is not feasible, the testing coordinator will develop procedures and\ntest the user interface manually.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsamcrow%2Fcook-e-process","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsamcrow%2Fcook-e-process","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsamcrow%2Fcook-e-process/lists"}