Through this project, we hope get a better understanding for how different technical and mathematical signals can be incorporated into sophisticated machine learning models. Improving our knowledge of finance, data science, and web development.
We are seeking to evaluate the predictive power of indicators, correlated assets, mathematical metrics, and public sentiment analysis to build a portfolio with a better Sharpe Ratio than the S&P500.
Our goal is to develop a web application that allows us to build, manage, and maintain a portfolio using our models in a way that can be reproduced for us by people outside our firm.
We want to get As.
| Medium | Expected Response Time | Uses |
|---|---|---|
| Slack | <1 hour | Sharing Files with One Another, Daily Communication |
| Texting | <30 min | Emergency |
| <2 hours | Communication with Outsiders |
| Meeting | Day(s)/Times | Function | Advance to Reschedule/Call | Location |
|---|---|---|---|---|
| Bi-Weekly | Monday(5pm), Friday(2pm) | Stand-Up (AGILE) | At Previous Meeting | Various |
| Weekly | Sunday(2pm) | Development | Four Days | Reserve Room |
| Impromptu | As Needed | N/A | Two Hours | N/A |
Milestones are to be agreed upon at the end of every weekly meeting. At the end of the following week's meeting, the group will assess each member's performance on their goals. If three straight weeks or four of five weeks pass with a person not meting expectations, the penalty will be invoked.
Attendence is required at every meeting unless proper notice is given. Failure to attend a super-majority of meetings in a two-week period invokes the penalty.
| Cause | Penalty |
|---|---|
| Missing Goals | Rat |
| Missing Meetings | Rat |
If two people disagree, both ideas will be explored if possible. Otherwise, the third group member makes the decision.
This team is organized as follows.
| Role | Primary | Content |
|---|---|---|
| Tasking Manger | GitHub Mgmt. | Milestones, Delegating Work, Branch Mgmt. Code Mgmt. |
| PR Manager | Comms | Coordinating with Outside World |
FML Partners believes hard work beats talent when talent doesn't work hard. But if you have both... you're set.
When working on the implementation of additional features, we will create individual branches for whatever each person is working on. Only once the code has been demonstrated to operate exactly as the developer intended in a way that does not interfere with the functionality of the rest of the project can they merge into master.
Generally speaking, members should not alter/modify code that was written by another member unless they are explicitly asked to or have explicitly been given permission to do so.
Upon completion, code should be appropriately commented for the clarity of other members in the group unless its functionality is already inherently clear (eg, one-line functions generally shouldn't need to be described, but a convolluted data transformation probably should be).
Perhaps most importantly, your code is your responsibility! If you wrote something that breaks in the future, it is your responsibility to figure out why and make that fix to allow for further advancement of the proejct.