gatorincubator / irbeast Goto Github PK

Codecov & the coverage is not currently working for one reason or another. It may be as simple as us not having a test suite for it to use yet. However, clicking upon its button tells me that I do not have permission to view it from access from its key. This could be a button problem but I do not believe that to be the case.

I suggest that Travis CI be setup with the repository so that continuous integration can occur with all pull requests made.

In order to automatically check the format of the name of the files being uploaded instead of just having users check that as a part of the "DO list". We should look into what regex command we can use for detecting if the file name is indeed in the desired form and be able to use in the program for checking it immediately after the file is uploaded upon the completion of all items of the checklists.

As we begin to add code to the repository, we must consider how we will track the coverage of it by test cases so that we may have 100% or as much as possible covered. I believe that codecov.io will work best for doing this.

This is very unimportant, but it will be a good choice for the sake of polish.

In order for this to be made available as a public repository people can use the code from, we should include a LICENSE file. I suggest that we use an MIT License.

Update the readme to reflect what this tool will be used for and how to use it.

bullet seems to have a display problem with items that go over and end up using word wrap, as seen by this issue. In order to avoid this problem, anticipating that we will have detailed questions that would need word wrap or at the very least could have them, it should be looked into how to use a script to maximize the terminal window as this avoids word wrap. This stack exchange post seems to deal with the exact question this issue raises and hopefully will be able to be applied to the terminal window.

People should follow the tutorials on this Workshop to gain an understanding of how Chalice works and how we will be interacting with it.

As we continue the setup of the foundation of the repository, we should add all relevant status badges to the README.md. #3 would see a badge for Travis CI, #4 would see a badge for CodeCov, and when we add code a badge for Python would also be warranted.

We should develop a list of good traits that exist in an IRB proposal to maximize the likelihood of a successful IRB proposal submission.

We need a final name for the project at some point.

At this time, issue #11 cannot be finished and #20 cannot be merged without Travis encryption first. This is explained in the Travis CI Docs.

The README.md was created with minimum information it and thus needs to be expanded with at least more of a description of what the tool will be.

Adding these templates should be considered in order to make it easier to contribute to this as an open source project and provide uniformity. The need for these are outlined here. These files are also suggested on the Community page.

Currently, the message "No description, website, or topics provided." appears on the homepage of the repository and should be replace with a simple description, ideally starting with an emoji to continue the format of other repositories in the GatorEducator organization (might I recommend the following options of: 📝, 🗒️, 🐲, 🐊, 🐻, 🦁, 🐯, 🐂, 👹, or something along these lines). Topics such as python and maybe some others like tool & checklist should also be added. Both of these things will need to be done by someone with maintainer status and thus those with that access have been assigned to this issue.

Come up with a checklist of bad IRB proposal traits for use as a checklist.

For this we will want to use AWS Chalice to send and receive the checklist and a .pdf of the proposal to be submitted. This will be accessed by whoever the professor that is checking the quality of the proposal is within the department. They will then be able to download the proposal and send it off to the IRB if it passes.

In order to avoid committing files to the remote repository from our local ones, we should include a .gitignore file even if at first it is basic and generic.

We should have some base code that displays a checklist that the user can interact with and can then be modified and built upon. The code I have in the bullet-tests branch can be modified to meet this and then pull requested into the master.

As we write functions and code we should also have tests for each to ensure that a newer version or alternative version of IRBeast is working properly.

In order to improve the state of this project as an open source one, these proposed files should be included to make it easier to contribute in a productive way in accordance with the need outlined here. I suggest that the Code of Conduct be taken from here to avoid having to create one from scratch. GitHub also has some suggestions for making a Contributing file that can be found here. These files are also suggested on the Community page. Also, here is a CONTRIBUTING.md file that I made for another project, AVMf