Mandatory progress report sections

[han-so1omon]

Instead of prefilling a singular text box we should look into having multiple sections for each part of the progress report to be filled in so that "required" sections can't be deleted and the proposal contents become more standardized

Thoughts?

[BennyOptions]

Agree - for development projects specifically I think a link to the repo to verify progress should be mandatory, and the repo should be stored here, in the icon-community org.

https://github.com/icon-community

[han-so1omon]

Which repo? I don't think projects should be required to be developed under the icon-comunity org if that's part of what you're stating

As of now I believe the progress reports are mandatory. This issue is about making specific mandatory sections as well, which requires redesigning the progress report UI and perhaps adding some verification on the backend

Any information detailing this should be in the cps wiki https://github.com/icon-community/cps/wiki

[BennyOptions]

Edited original post to clarify. It's public funding by ICON validators so it's my opinion that the repo should be stored in the community organization to keep community-funded projects easy to find for other developers. If all publicly funded projects are kept separately, and not actively updated in docs.icon.community, it would be easy for publicly funded services to be forgotten about leading to wasted money.

[han-so1omon]

I don't think forcing code ownership and repo management is the best way to support a community. It's more typical for publicly funded code projects to be managed by external development organizations, but to rely on the funding organization to guide them to the best chance at success

icon-community organization is something I started so that the teams have the option to develop within the envelope of the at-large community for immediate reach to collaborators and technical users. It helps if the project is intended to be handed off to the community or something similar. Different development organizations have different goals and development plans, though, including for documentation

Better incubation strategies, such as beta testing plans, co-marketing efforts, RFP collaborations, case study/feedback groups, etc. are a much better path forward in my opinion

[BennyOptions]

Sure, my question is how will new developers find all the work already done by the ICON community? How would the find Drogon as an example? Or the ICON Bridge SDK developed by Espanicon? Or the analytics tools funded here? Just a few examples.

[han-so1omon]

For example, the icon-community/awesome-icon repo or the official docs when appropriate. Or co-marketing and product highlighting, as is being done through Twitter, discord, etc. Or the standard of responsibility for a development team, to do promotion on their product and make it known to the community

[CyrusVorwald]

Depending on the nature of the project, some sections may not be relevant. For example, if I am hosting a meetup instead of coding, any section related to software development is irrelevant to me. Currently, these include the Instructions to run tests, Link to license, Sample of docs, Security analysis, and Semantic versioning / branching analysis.

Also, the budget amendment section is irrelevant to the CPS and should be removed.

[han-so1omon]

Maybe we can aim to separate between 'code' and 'non-code', then have conditionally mandatory sections. There should be a separate progress report and grant template in the works for comms/media-type grants

[CyrusVorwald]

Agreed, that was the motivation to change the project categories here https://github.com/icon-community/CPS/issues/67#issue-1473654030. The current categories are somewhat vague and could overlap. This way, proposal and progress report can be based on the project category.

[han-so1omon]

I like those categories, and I support that plan