HowToCook/CONTRIBUTING.md

# CONTRIBUTING Guide

## 如何贡献

直接修改/添加做菜指南并提交 Pull request 即可。

在写新菜谱时，请复制并修改已有的模板: [示例菜](./dishes/template/示例菜/示例菜.md)。

记得在提交 Pull Request 前同样更新一下 Readme.md 里的引用。

## 为什么会有这个项目 (Motivation)

- Anduin的Motivation

最近在家隔离，出不了门。只能宅在家做饭了。作为程序员，我偶尔在网上找找菜谱和做法。但是这些菜谱往往写法千奇百怪，经常中间莫名出来一些材料。对于习惯了形式语言的程序员来说极其不友好。

所以，我计划自己搜寻菜谱和并结合实际做菜的经验，准备用更清晰精准的描述来整理常见菜的做法，以方便程序员在家做饭。

- Recolic的个人观点

菜谱的目的是复现一道菜。在做菜的过程中，菜会受厨师的经验、主观判断、生活经历而改变。
但是为了达到`复现一道菜`的目的，菜谱必须是客观的，也就意味着菜谱本身不应受厨师的经验、主观判断而改变。  
菜的创作者(厨师)、菜的记录者(菜谱)、菜的生产者(饥饿的程序员、炒菜机器人)应当是三个不同的角色。如果生产者偶尔心情愉悦，可以兼职为创作者。记录者是为生产者服务的。

## 内容规范

本项目的Motivation要求菜谱满足以下规范，不符合规范的菜谱将不会被合并到代码库中。如果以下内容不易理解, 不必担心. 仓库管理者会在你的PR中提出建议, 并协助修改。

1. 每一道菜谱至少应包含`原材料与工具`, `计算`, `操作`三部分内容。

`原材料与工具`应列出本菜品需要的除`假想已准备好的物品`外的所有原材料与厨具。  
`计算`应定量列出本菜品所需的原材料的量。（无论与人数是否相关）   
`操作`应说明菜品的制作步骤。

2. 菜品的制作步骤应当明确(无歧义,non-ambiguous)，并尽可能准确(accurate)。有歧义(ambiguous)的描述是不可接受的，而不准确(inaccurate)或不精确(imprecise)的描述是可以接受的。

> 不准确的菜谱会导致菜品口味有少许偏差，不明确的菜谱会导致做菜人的心态有明显不安。

举例：有歧义的描述

```
# 解释：此处对于盐量的描述是有歧义的。
#       因为对于某个数量的盐，用户无法得出确定的客观结论：此数量是否属于"少量"。
加入少量盐

加入几滴耗油
将锅加热至八分热
撒上少许葱花
煮至鸡肉断生
```

举例：无歧义的描述

```
# 解释：此处对于锅的温度的描述是不准确的（可能是200摄氏度左右的任何温度），但这个描述是无歧义的。
#       因为对于锅的某个状态，用户可以进行水滴测试，并得出确定的客观结论：此状态要么符合要求，要么不符合要求。
加热锅，直至"滴入几滴水时，水珠能够在锅上迅速滚动而不吸附"
加热锅，直至观察到莱顿弗罗斯特现象

加入5ml酱油
等到水沸腾后
继续煮，直到汤汁剩下二分之一
煎至表面呈金黄色
继续翻炒两分钟

# 食材所可能粘附的蛋液的量是确定的
裹上蛋液

# 在'计算'中已提及将用到葱花的量
撒上葱花
```

考虑到现实因素，对于某些在家庭厨房中确实难以明确描述的因素，可以作为特例排除。例如

```
# 在描述燃气灶火焰强度时
文火, 小火, 中火, 大火 等
# 在描述颜色时
金黄色 等
# 在描述硬度时
变软 变硬
```

3. 菜品的`制作步骤`应当完整(complete)。这意味着, 在执行完所有操作步骤后, 菜品已经被完成。

4. 菜品的`原材料与工具`应当完整(complete)且必要。这意味着, 在执行完所有操作步骤后, 没有原材料被遗漏不用。在执行操作步骤时, 没有用到`原材料与工具`中未提到的物品。