Some notes about the proposal feedback. The direactor of the group reminds us that it is good to learn from the refused proposal, and I try to take some nots in this blog according to the feedback that is refused, and try to list some key points here.
从评审人的角度考虑的几个宏观问题
1 整个大的学科领域，是否值得资助研究，是否还是比较热的研究大方向。
2 小的细分领域，是否值得资助研究，有新的研究价值。
3 细分领域，有没有别人在做。没有的话就好说，有的话 ，你的特色是什么，跟别人不同的点。
4 你有没有能力按照所说的内容做出来。
5 怎么衡量你做出来的这个内容的效果。
如果这几个问题都能回答的比较好，或者超过平均的水平，这个proposal中的概率就比较大，前两个问题千万不要有硬伤，因为这个是比较客观的因素，如果入手点就选错了，后面再费劲也很难有好的结果。
Falsifiable scientific hypothesis
One question to answer in the proposal feedback is about the flasifiable hypothesis, if the proposal contanis the 可证伪的假说，and if this thing is valuable.
之前写paper的时候很少从这个角度考虑问题，似乎科学的理论，一般都是“可证伪、且未被证伪”的。
下面是网上的关于可证伪性的一些论述：
“不可证伪”其实就是那种“永远都不会错”的无赖逻辑。所以科学必须是可证伪的。注意，可证伪性并不等于已经证伪，也就是说，你不必真的去找黄色的树叶，也不必真的去找烧煤的恒星，“如果我能找到，那么你就错了”这就叫可证伪。
波普尔把“可证伪性”作为衡量一个理论“科学性”的标准——可证伪性越强，科学性就越强，没有可证伪性，就没有科学性。
创新性的表述
通常的创新性就是之前说的AMD，新的体系，方法，数据，场景等等，如果paper做出来了，contribution里面自然可以有很多的表述，比如性能，速度提升了多少，但是在写项目书的时候这些细节还没做出来，这些是一些类似的例子：
基本的思路是：将创新点分段、分层说明，以增强逻辑性和说服力：
背景描述：说明问题或现状。
创新性内容：突出你的核心方法或理论。
可能的影响：展望潜在成果和意义。
因为不可能是你自己说是创新，就是创新了，一定要有理有据。创新方式的表述可能有很多种，但是以下几种应该是比较常见的：
提出了新的方法或者理论
提出基于XXX的YYY新理论（理论上的创新）
当前的YYY研究主要采用AAA方法，但其在处理ZZZ问题时效率低下。本项目拟提出一种基于XXX的新理论框架，旨在提升对ZZZ问题的描述能力。初步理论分析表明，该框架具有更高的鲁棒性和适应性。
背景首先是说明针对的是什么什么问题，本问题提出了xxx方法框架，旨在提升xxx。初步的理论分析，该框架方法有xxx样的效果。
这种可能是难度比较高的，很具有原创性的创新，比如美好心灵电影里的Nash提出的博弈论这种程度类型，可能就属于原创的理论，应该是一般人很难做到的程度了，特别是理工科。
还有一种比如周志华老师提出的这种learnware学件的概念，有点类似于huggingface这种不同模型的组合，提出了一个大的概念之后，往往后续可以进行一系列的细致的探索，是一种很有开创性的工作。
在理工科的场景下，后面两种可能是比较常用的类型：
某种技术应用在了其他的场景
开发针对XXX问题的YYY工具，比如：
现有工具多针对AAA场景，难以适应复杂的BBB环境。本项目计划开发一款针对XXX问题的专用工具，通过YYY技术实现数据处理效率的显著提升，填补BBB场景工具的空白。
借鉴技术发展趋势 ，引用其他领域的技术趋势或新工具，表明这些技术在你的研究场景中具有潜在的创新应用价值。
示例：近年来，XXX技术在YYY领域展现出强大的潜力。然而，其在ZZZ场景中的应用尚未展开。本研究将首次尝试将XXX技术引入ZZZ领域，通过开发特定算法，实现对AAA问题的高效解决。
常见的就是已有方法使用了新的硬件计算架构，已有方法使用到了新的数据或者新的应用场景下等等，总之要想办法能说明一个”新”字，不管是从哪个角度的新，总之这个事情需要是一定程度上别人没有做过的事情。
强调已有方法在已有应用基础上的改进
即使没有完成实验，可以重点描述你的方法设计与现有方法的不同之处，突出它的潜在优势。
示例：本研究拟设计一种基于XXX的改进型算法，通过优化YYY计算流程，有望在ZZZ问题上实现性能提升。同时，该方法的模块化设计为进一步扩展到AAA领域提供了可能。
If the hypothesis can be assessed
One reason for refusal for our proposal is that it can not provide a solid evaluation approach. The reviewer said they don’t know how the thing we described can be assessed.
Maybe the thing that can be assessed follows the same pattern, such as “sth can improve the accuracy/save resource/improve the speed in how much” If the hypothesis does not follow this pattern in CS domain, it might not the right thing or proper description for the problem. You could also say that the approach is helpful for doing sth or facilitate the other things, but it is important to try to move another step, answering how this is helpful in quantitatively is important to make it be assessable.
However, it seems that in computer science or software engineering, the falsifiable is not that much relevent, see this question, I’m a little bit confused about it. Although some topics in cs is not fully relevent to the concept of falsifiable, at least, the clear metric about the assissibility and to show that the thing you work on is good, is critial section in proposal. (How to evaluate the presented approach, and how to refine the presented approach during the lifetime of the project)
Clearly, if you could not show to the reviewer if your things is good or not good, the reviewer will have no ideas and will give a refusal at last. Without this evaluation (or some prototype for the proof of concept), you can not show if the method or approach is doable.
Otherwise, reviewer might provide some senteces like:
The abstract goals are great, but the linkage to reality was too tenuous.
I was not able to really evaluate this with the level of specifics presented.
Scope, assumption and requirements
Two aspects
One aspect is to evaluate if your institution have enough ability to conduct this research, such as do you have enough device, background in related field and people to do that. Another is the quality of the proposal (the points mentioned above), the proposal will be approved when both of these two aspects are good.
Key questions
It might be easier to evaluate a proposal compared with wrting a proposal from scratch. I recently know some rules about evaluating the proposal, which is called Heilmeier’s Catechism there are all kinds of online resources about it, this is one official version. I put it here. When writing a proposal, just assume you are a reviewer and asking yourself about these questions back and forth. Just use these questions as a template to write the proposal or paper.
The first three are basically the necessary question for writting a paper.
What are trying to do can be used to convey ideas to someone in leadership position quickly. Typical way is three sentences template, 背措效, backgound, method, effects (such as how much speed or resource cost is improved/saved).
Second and third are usually related. The limitation of current works is the new things for your approach. The typical new aspect in cs comes from using new architecture, using new data, using existing approch in a new scenarios, and new method. The new is not the goal, the goal is to make things(targeted metric) better.
the subsequent ones are hard to answer, it is the question that are really important and motivate you from the pure research to the research that can make out sth useful, or deliver sth useful. Who cares and what difference will it make is really important.
