Development Roadmap Proposal

[H0R5E]

Hi, I would like to propose the development of a roadmap for helping us to organise and prioritise the development and deployment of this code and to develop team's working practises.

I believe the roadmap should contain 6 main section headings as follows:

• Organisation <- relating to ourselves
• Features <- Planning / code related to the business logic
• Implementation <- Planning / code not related to the business logic
• Testing <- both integration and unit tests
• Documentation <- located within the repository or otherwise
• Deployment <- considering the need of users and developers

I suggest we put this into a text file in the repository's root directory. (I considered using the wiki, but there is no code review support for the wikis on GitHub))

Within each section will be a list of tasks / proposals with a description, a status, and a link to further details. I propose that detailed discussion about each task be conducted in the issue tracker, opening an issue for each task, as it becomes active.

I strongly suggest we use the request/review/pull features of GitHub to update the roadmap, so that updates can be approved by the team before being submitted. If you're unfamiliar with this process, you can read about it here:

about-forks creating-a-pull-request-from-a-fork

I can also help people out with this. I think it's good to start working this way in general, as this is how external developers of the code will approach working with us.

Let me know if you guys are happy with the general concept or want to change anything, and then I will add a pull request with the draft version.

Cheers,

Mat

[ryancoe]

Mat - Thanks for taking the initiative on this. I'll set up a phone call for further discussion, but I encourage the rest of the team to comment here.

My preference for a git strategy is to use gitflow.

On a related topic, I'd like to get rid of git-lfs on this repo for the time being. Due to folks' lack of experience with this, we've eaten up a lot of storage space. From my reading, there's no easy way to remove the lfs files (you have to remove them from the history as well). @H0R5E - Perhaps you can take a look into this (#36)?

[H0R5E]

Hi Ryan,

My experience says it is better to avoid branching (EDIT: of the main repository) altogether and simply use pull requests. This can be a little tedious if you want to make small changes, but it perhaps encourages a more careful approach to updating code - especially once you have some continuous integration practices in place. Happy to give gitflow a try, if you want, but I suspect it may be overkill for us at this point.

Regarding SNL-WaterPower/WecOptTool_old#36, one of the proposals I am going to make in the roadmap is to reset the repository. The PDF files and their history have pushed the repo size to 900MB and it's just a pain in the arse to clone it. We would sort out a functional clean branch (like the dev branch), delete the repository and then restart it using that branch as the master. Obviously, a clone of the old repository could still be used for the paper development, but all code work would then take place in the clean repo.

[ssolson]

Mat thanks for your work on this.

With respect to the forking vs. gitflow I can say that we took the forking approach for MHKit and it worked well. I have not practiced gitflow before but I think it leans towards overkill at this point. My vote is for forking.

I like the 6 roadmap points you propose and look forward to a full discussion Monday. I want to point out that the reason for the current code structure is that we are releasing a case study of the RM3. The functions as-is are written specifically for RM3 so I have opted to contain them there until generalized. I do agree with the long term plan to move the code toward a generalized structure as in your proposed layout.

[H0R5E]

Closed by SNL-WaterPower/WecOptTool_old#40