Initial commit. New repo for non-technical documentation
This commit is contained in:
61
BusinessDocumentation/BusinessPlans/AUP.md
Normal file
61
BusinessDocumentation/BusinessPlans/AUP.md
Normal file
@@ -0,0 +1,61 @@
|
|||||||
|
**Acceptable Use Policy (AUP)**
|
||||||
|
|
||||||
|
**Effective Date:** ___ [Date] ___
|
||||||
|
**Issued by:** **Midas Technologies LLC**
|
||||||
|
|
||||||
|
This Acceptable Use Policy (“Policy”) governs the use of **Midas Technologies LLC**’s software, platform, and related services (collectively, “Services”) by all users, clients, and third parties. By accessing or using our Services, you agree to comply with this Policy and all applicable laws.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 1. **Purpose**
|
||||||
|
- The purpose of this Policy is to promote the responsible, secure, and lawful use of Midas Technologies LLC’s Services and to protect the interests of the Company, our users, and the community.
|
||||||
|
|
||||||
|
### 2. **Permissible Use**
|
||||||
|
- **Service Access**: Users are permitted to access and use the Services solely for their authorized and intended purposes, as agreed upon with Midas Technologies LLC.
|
||||||
|
- **Account Responsibility**: Users are responsible for maintaining the confidentiality of their login credentials and all activity under their accounts.
|
||||||
|
- **Compliance**: Users must comply with all Company policies and applicable local, state, and federal laws, as well as regulations governing online conduct and data usage.
|
||||||
|
|
||||||
|
### 3. **Prohibited Actions**
|
||||||
|
Users are strictly prohibited from engaging in the following activities:
|
||||||
|
- **Unauthorized Access**: Attempting to gain unauthorized access to our Services, servers, networks, or user accounts by hacking, password mining, or any other means.
|
||||||
|
- **Distribution of Malware**: Uploading, distributing, or transmitting viruses, malware, or any other malicious code that could disrupt or damage the Services or any user’s software or hardware.
|
||||||
|
- **Data Harvesting**: Collecting or attempting to collect information about other users without their consent, including through web scraping or other automated processes, unless explicitly authorized by the Company.
|
||||||
|
- **Spamming and Abuse**: Engaging in spamming, phishing, or any abusive or disruptive activity that could interfere with the use of the Services by others.
|
||||||
|
- **Illegal Activity**: Using the Services to support or engage in any activity that is illegal, fraudulent, or violates the rights of others, including intellectual property rights.
|
||||||
|
- **Reverse Engineering**: Reverse engineering, decompiling, disassembling, or otherwise attempting to derive the source code or underlying algorithms of the Services, except as permitted by applicable law.
|
||||||
|
|
||||||
|
### 4. **User-Generated Content**
|
||||||
|
- **Content Responsibility**: Users are solely responsible for the content they submit, post, or display through the Services and must ensure that it does not violate any laws or this Policy.
|
||||||
|
- **Inappropriate Content**: Users may not upload or share content that is defamatory, offensive, harassing, threatening, discriminatory, or otherwise inappropriate.
|
||||||
|
|
||||||
|
### 5. **Consequences of Misuse**
|
||||||
|
- **Suspension or Termination**: Violation of this Policy may result in the suspension or termination of the user’s account and access to the Services, at the Company’s sole discretion.
|
||||||
|
- **Legal Action**: Midas Technologies LLC reserves the right to pursue legal action, including seeking damages or injunctive relief, against users who violate this Policy.
|
||||||
|
- **Recovery of Costs**: Users who engage in prohibited activities may be held liable for any costs incurred by the Company, including those associated with investigating or responding to violations, as well as potential legal fees.
|
||||||
|
|
||||||
|
### 6. **Reporting Violations**
|
||||||
|
- **How to Report**: If you become aware of any violation of this Policy, please report it immediately to our support team at [Contact Email].
|
||||||
|
- **Anonymous Reporting**: Users may report suspected violations anonymously, although providing contact information may assist us in conducting a thorough investigation.
|
||||||
|
|
||||||
|
### 7. **Monitoring and Enforcement**
|
||||||
|
- **Right to Monitor**: Midas Technologies LLC reserves the right, but is not obligated, to monitor the use of our Services to ensure compliance with this Policy.
|
||||||
|
- **Investigative Action**: We may investigate potential violations and take appropriate action, including contacting law enforcement, to address illegal or unauthorized activities.
|
||||||
|
|
||||||
|
### 8. **Disclaimer of Liability**
|
||||||
|
- **No Liability for Third-Party Actions**: Midas Technologies LLC is not liable for any content posted by users or any third-party actions that violate this Policy. We do not control user behavior and are not responsible for any misuse of the Services.
|
||||||
|
|
||||||
|
### 9. **Amendments to this Policy**
|
||||||
|
- Midas Technologies LLC reserves the right to modify or update this Policy at any time to reflect changes in our practices, legal requirements, or regulatory obligations. Notice of any significant updates will be provided on our website or through direct communication with affected users, where applicable.
|
||||||
|
|
||||||
|
### 10. **Contact Information**
|
||||||
|
For questions regarding this Acceptable Use Policy, please contact us at:
|
||||||
|
|
||||||
|
**Midas Technologies LLC**
|
||||||
|
Address: [Business Address]
|
||||||
|
Email: [Contact Email]
|
||||||
|
Phone: [Contact Phone Number]
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
By accessing or using our Services, you agree to comply with this Acceptable Use Policy. Violations of this Policy may result in account suspension, termination, or further legal action, as deemed appropriate by Midas Technologies LLC.
|
||||||
|
|
||||||
@@ -0,0 +1,57 @@
|
|||||||
|
**Confidentiality Agreement**
|
||||||
|
|
||||||
|
**This Confidentiality Agreement ("Agreement")** is entered into as of ___ [Date] ___, by and between **Midas Technologies LLC** (the "Company") and ___ [Contractor/Vendor Name] ___ (the "Recipient").
|
||||||
|
|
||||||
|
**1. Definitions**
|
||||||
|
- **Confidential Information**: “Confidential Information” refers to any and all proprietary information, trade secrets, data, know-how, and other information, whether in written, oral, electronic, or other forms, disclosed by the Company to the Recipient. This includes but is not limited to:
|
||||||
|
- Proprietary trading algorithms, software, code, data models, economic analysis, strategies, and technical indicators.
|
||||||
|
- Financial data, business plans, marketing strategies, client lists, and vendor relationships.
|
||||||
|
- All other non-public information concerning the Company's business and technology.
|
||||||
|
|
||||||
|
**2. Obligations of Confidentiality**
|
||||||
|
- **Non-Disclosure**: Recipient agrees not to disclose, disseminate, or share any Confidential Information with any third party without prior written consent from the Company.
|
||||||
|
- **Use Restriction**: Recipient agrees to use the Confidential Information solely for the purpose of providing services to the Company and not for any other purpose, including personal or commercial use.
|
||||||
|
- **Protection Measures**: Recipient shall take all necessary precautions to prevent the unauthorized disclosure or use of Confidential Information, including implementing reasonable security measures.
|
||||||
|
|
||||||
|
**3. Exclusions from Confidential Information**
|
||||||
|
- Confidential Information does not include information that:
|
||||||
|
- Was publicly known or available prior to disclosure by the Company;
|
||||||
|
- Becomes publicly known or available through no wrongful act of the Recipient;
|
||||||
|
- Was already known by the Recipient at the time of disclosure, as proven by written records; or
|
||||||
|
- Is independently developed by the Recipient without the use of or reference to the Company’s Confidential Information.
|
||||||
|
|
||||||
|
**4. Return or Destruction of Materials**
|
||||||
|
- Upon completion or termination of the business relationship or upon request by the Company, the Recipient agrees to promptly return or destroy all materials containing Confidential Information, including electronic files and backup copies. Recipient shall provide written certification of such destruction if requested by the Company.
|
||||||
|
|
||||||
|
**5. No Ownership or License**
|
||||||
|
- This Agreement does not grant the Recipient any rights, title, or interest in the Confidential Information, except the limited right to use it for the purposes of their contractual obligations. No license, express or implied, is granted by the disclosure of Confidential Information.
|
||||||
|
|
||||||
|
**6. Remedies**
|
||||||
|
- **Injunctive Relief**: Recipient acknowledges that a breach of this Agreement may cause irreparable harm to the Company. Accordingly, the Company is entitled to seek injunctive relief, in addition to any other available remedies, to enforce this Agreement.
|
||||||
|
- **Indemnification**: Recipient agrees to indemnify and hold the Company harmless from any damages, losses, or costs arising from unauthorized disclosure or misuse of the Confidential Information.
|
||||||
|
|
||||||
|
**7. Term and Termination**
|
||||||
|
- **Duration of Obligation**: The Recipient’s duty to maintain the confidentiality of the Company’s information shall remain in effect for a period of **[2-5 years]** following the termination of this Agreement or the business relationship, whichever is longer.
|
||||||
|
- **Termination**: Either party may terminate this Agreement upon thirty (30) days’ written notice. However, the confidentiality obligations outlined here shall survive termination.
|
||||||
|
|
||||||
|
**8. Governing Law**
|
||||||
|
- This Agreement shall be governed by and construed in accordance with the laws of the State of [Your State].
|
||||||
|
|
||||||
|
**9. Entire Agreement**
|
||||||
|
- This Agreement constitutes the entire understanding between the parties regarding the subject matter and supersedes all prior agreements, representations, or understandings, whether written or oral.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Signatures:**
|
||||||
|
|
||||||
|
**Recipient (Contractor/Vendor):**
|
||||||
|
___ [Recipient Name] ___
|
||||||
|
Signature: ___________________________
|
||||||
|
Date: ___
|
||||||
|
|
||||||
|
**Midas Technologies LLC:**
|
||||||
|
By: ___ [Authorized Representative Name] ___
|
||||||
|
Title: ___________________________
|
||||||
|
Signature: ___________________________
|
||||||
|
Date: ___
|
||||||
|
|
||||||
@@ -0,0 +1,77 @@
|
|||||||
|
Here’s a comprehensive **Cybersecurity Policy** for **Midas Technologies LLC**. This policy sets standards to protect proprietary information, including data models, software, and client data, and ensures compliance with best practices in cybersecurity.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Cybersecurity Policy**
|
||||||
|
|
||||||
|
**Effective Date:** ___ [Date] ___
|
||||||
|
**Issued by:** **Midas Technologies LLC**
|
||||||
|
|
||||||
|
This Cybersecurity Policy (“Policy”) provides the framework for **Midas Technologies LLC** to secure its information systems, protect proprietary and client data, and prevent unauthorized access to sensitive information. This Policy applies to all employees, contractors, and any third parties with access to the Company’s information systems.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 1. **Purpose and Scope**
|
||||||
|
- **Purpose**: The purpose of this Policy is to establish cybersecurity practices and procedures to safeguard the Company’s information systems, proprietary data, and other sensitive information.
|
||||||
|
- **Scope**: This Policy applies to all Company-owned or -operated devices, networks, software, and any data handled by employees, contractors, and third-party partners.
|
||||||
|
|
||||||
|
### 2. **Data Encryption Requirements**
|
||||||
|
- **Data in Transit**: All sensitive information transmitted over networks, including proprietary algorithms and client data, must be encrypted using TLS/SSL or comparable industry-standard protocols.
|
||||||
|
- **Data at Rest**: Sensitive data stored on servers, databases, and employee devices must be encrypted with AES-256 encryption or another industry-standard encryption protocol to ensure data security.
|
||||||
|
- **Encryption Keys**: Access to encryption keys is restricted to authorized personnel only, and all keys are managed securely to prevent unauthorized access.
|
||||||
|
|
||||||
|
### 3. **User Access Controls**
|
||||||
|
- **Role-Based Access**: Access to data and systems is restricted based on job function. Employees are granted only the minimum access necessary to perform their duties.
|
||||||
|
- **Two-Factor Authentication (2FA)**: All user accounts with access to sensitive data or systems must be secured with 2FA to prevent unauthorized access.
|
||||||
|
- **Password Policy**: Employees are required to use complex passwords that meet the Company’s standards (minimum length, use of special characters) and to update passwords every 90 days.
|
||||||
|
|
||||||
|
### 4. **Device and Network Security**
|
||||||
|
- **Device Security**: All Company devices, including laptops and mobile devices, must have up-to-date antivirus software and firewalls enabled. Only approved devices are permitted to connect to the Company’s network.
|
||||||
|
- **Virtual Private Network (VPN)**: Remote access to the Company’s network must be done through a secure VPN to ensure the privacy and security of data transmissions.
|
||||||
|
- **Endpoint Monitoring**: The IT department monitors endpoints for suspicious activity and runs periodic security audits to assess and mitigate potential risks.
|
||||||
|
|
||||||
|
### 5. **Incident Response Plan**
|
||||||
|
- **Incident Identification**: Employees must report any suspected security incidents, including phishing attempts, unauthorized access, or malware infections, to the IT department immediately.
|
||||||
|
- **Response and Containment**: The IT team will assess, contain, and mitigate the impact of any identified security incidents, prioritizing the protection of data and system integrity.
|
||||||
|
- **Notification Protocols**: If sensitive data is compromised, the Company will notify affected parties as required by law and work to remediate the breach promptly.
|
||||||
|
|
||||||
|
### 6. **Compliance and Regulatory Requirements**
|
||||||
|
- **Legal Compliance**: Midas Technologies LLC adheres to applicable laws and regulations governing data protection, including [relevant laws, e.g., GDPR if applicable].
|
||||||
|
- **Periodic Compliance Audits**: The Company conducts annual audits of its security practices to ensure compliance with this Policy and applicable regulations.
|
||||||
|
|
||||||
|
### 7. **Data Protection and Privacy Measures**
|
||||||
|
- **Data Minimization**: Only data necessary for operational purposes is collected and stored. Sensitive data is handled in a way that minimizes exposure and risk.
|
||||||
|
- **Data Anonymization**: Where possible, data is anonymized to protect individual privacy and reduce the impact of potential breaches.
|
||||||
|
- **Third-Party Security**: Vendors and third-party partners with access to Company data are required to follow comparable security practices, and agreements must outline confidentiality and security obligations.
|
||||||
|
|
||||||
|
### 8. **Employee Training and Responsibilities**
|
||||||
|
- **Security Training**: All employees must participate in annual cybersecurity training, covering topics such as password management, phishing awareness, and data handling protocols.
|
||||||
|
- **Acceptable Use Policy**: Employees are required to follow the Acceptable Use Policy, ensuring responsible use of the Company’s network, software, and data.
|
||||||
|
- **Reporting Obligations**: Employees must immediately report lost or stolen devices, unauthorized access, or any suspected security incident to the IT department.
|
||||||
|
|
||||||
|
### 9. **Monitoring and Regular Audits**
|
||||||
|
- **Security Monitoring**: The IT department monitors network and endpoint activity for unusual behavior, potential threats, and unauthorized access attempts.
|
||||||
|
- **Regular Security Audits**: Biannual security audits are conducted to assess vulnerabilities, validate compliance, and improve defenses against potential cyber threats.
|
||||||
|
- **Penetration Testing**: The Company performs penetration testing annually to identify and address security weaknesses in its systems and applications.
|
||||||
|
|
||||||
|
### 10. **Disciplinary Actions for Non-Compliance**
|
||||||
|
- **Policy Violations**: Failure to comply with this Cybersecurity Policy may result in disciplinary action, including termination of employment or contract, depending on the severity of the violation.
|
||||||
|
- **Legal Recourse**: Midas Technologies LLC reserves the right to pursue legal action against any individual or entity found to have intentionally compromised the Company’s security.
|
||||||
|
|
||||||
|
### 11. **Policy Review and Updates**
|
||||||
|
- **Annual Review**: This Policy is reviewed annually and updated as needed to reflect changes in technology, business practices, or regulatory requirements.
|
||||||
|
- **Employee Acknowledgment**: All employees must sign an acknowledgment of this Policy, confirming their understanding and commitment to comply with cybersecurity standards.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Acknowledgment of Cybersecurity Policy**
|
||||||
|
|
||||||
|
By signing below, I acknowledge that I have read, understand, and agree to comply with the Midas Technologies LLC Cybersecurity Policy.
|
||||||
|
|
||||||
|
| **Employee’s Name** | **Signature** | **Date** |
|
||||||
|
|----------------------|---------------|----------|
|
||||||
|
| | | |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
This Cybersecurity Policy establishes rigorous protocols to secure sensitive information and respond to cyber threats, ensuring compliance with best practices. Let me know if you’d like additional details or specific requirements included in any section.
|
||||||
63
BusinessDocumentation/BusinessPlans/DataRetentionPolicy.md
Normal file
63
BusinessDocumentation/BusinessPlans/DataRetentionPolicy.md
Normal file
@@ -0,0 +1,63 @@
|
|||||||
|
**Data Retention Policy**
|
||||||
|
|
||||||
|
**Effective Date:** ___ [Date] ___
|
||||||
|
**Issued by:** **Midas Technologies LLC**
|
||||||
|
|
||||||
|
This Data Retention Policy (“Policy”) outlines the practices of **Midas Technologies LLC** regarding the retention, storage, and deletion of data, including operational, financial, and analytical data. This Policy ensures compliance with best practices, regulatory standards, and operational needs.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 1. **Purpose and Scope**
|
||||||
|
- **Purpose**: This Policy is intended to establish guidelines for data retention, deletion, and protection, ensuring that Midas Technologies LLC effectively manages its data lifecycle.
|
||||||
|
- **Scope**: This Policy applies to all data collected, processed, and stored by Midas Technologies LLC, including operational data, financial data, client data, and log files. It applies to employees, contractors, and any third parties handling Company data.
|
||||||
|
|
||||||
|
### 2. **Data Categories and Retention Periods**
|
||||||
|
Midas Technologies LLC organizes data into the following categories, each with a defined retention period to support business needs and compliance requirements:
|
||||||
|
|
||||||
|
| **Data Category** | **Description** | **Retention Period** |
|
||||||
|
|---------------------------|-------------------------------------------------------------------|--------------------------------|
|
||||||
|
| Operational Data | Data related to daily business operations, including project data, workflow, and team communications. | 3 years |
|
||||||
|
| Financial Data | Invoices, receipts, transaction records, and tax documentation. | 7 years (for tax and audit) |
|
||||||
|
| Analytical Data | Data used for performance analysis, model training, and backtesting. | 5 years |
|
||||||
|
| Log Files | System and application logs, including access and error logs. | 1 year |
|
||||||
|
| Backup Data | Copies of operational and critical business data for disaster recovery purposes. | 1 year |
|
||||||
|
| Regulatory Compliance Data | Records required for compliance with regulations, including audit trails. | Minimum of 7 years |
|
||||||
|
|
||||||
|
### 3. **Data Storage and Security**
|
||||||
|
- **Data Storage Locations**: All data shall be stored on secure, access-controlled servers located on-premises or with trusted cloud providers that comply with industry standards for security and data protection.
|
||||||
|
- **Access Control**: Access to data is limited to authorized personnel based on role and necessity. Security measures, including password protection and encryption, are applied to safeguard data integrity.
|
||||||
|
|
||||||
|
### 4. **Data Deletion Protocols**
|
||||||
|
- **Scheduled Deletion**: Data that has reached the end of its retention period will be permanently deleted from Company systems, unless subject to a legal hold or exception.
|
||||||
|
- **Secure Deletion Methods**: Midas Technologies LLC employs secure deletion methods for all electronic data, including data wiping and, where applicable, physical destruction for printed materials.
|
||||||
|
- **Exceptions for Legal Holds**: In the event of ongoing litigation or regulatory investigations, data related to such cases will be retained until legal action concludes and no longer required.
|
||||||
|
|
||||||
|
### 5. **Data Compliance Standards**
|
||||||
|
- **Compliance with Applicable Laws**: This Policy complies with relevant data management laws, including but not limited to data protection and financial record-keeping regulations.
|
||||||
|
- **Audit and Monitoring**: Midas Technologies LLC may periodically audit data retention practices to ensure compliance with this Policy and applicable legal standards.
|
||||||
|
|
||||||
|
### 6. **Data Retention Responsibilities**
|
||||||
|
- **Data Owners**: Department heads and data owners are responsible for ensuring compliance with this Policy and reporting any issues related to data retention and deletion.
|
||||||
|
- **IT Department**: The IT Department is responsible for implementing data retention schedules, securing data storage, and performing scheduled data deletions.
|
||||||
|
- **Legal and Compliance Team**: The Legal and Compliance Team monitors data retention to ensure it aligns with regulatory and legal requirements.
|
||||||
|
|
||||||
|
### 7. **Review and Amendment of Policy**
|
||||||
|
- This Policy will be reviewed annually and updated as necessary to reflect changes in legal requirements, industry standards, and Company practices. Any updates will be communicated to all employees and relevant stakeholders.
|
||||||
|
|
||||||
|
### 8. **Exceptions and Legal Hold**
|
||||||
|
- **Exceptions**: Requests for exceptions to the retention periods defined in this Policy must be submitted in writing to the Legal and Compliance Team for review and approval.
|
||||||
|
- **Legal Hold**: In the event of a legal hold, all relevant data will be retained until the hold is lifted by the Legal and Compliance Team.
|
||||||
|
|
||||||
|
### 9. **Policy Acknowledgment**
|
||||||
|
- All employees and contractors handling Company data are required to sign an acknowledgment of this Policy, confirming their understanding of and commitment to adhering to these data retention standards.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Acknowledgment of Data Retention Policy**
|
||||||
|
|
||||||
|
By signing below, I acknowledge that I have read, understand, and agree to comply with the Midas Technologies LLC Data Retention Policy.
|
||||||
|
|
||||||
|
| **Employee’s Name** | **Signature** | **Date** |
|
||||||
|
|----------------------|---------------|----------|
|
||||||
|
| | | |
|
||||||
|
|
||||||
@@ -0,0 +1,57 @@
|
|||||||
|
Here’s a **Data Use and Privacy Policy** tailored for **Midas Technologies LLC**, specifically addressing the use of financial and public data. Since your data sources include web scraping and API access without handling personal data, the policy will focus on transparency, data security, and responsible data use.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Data Use and Privacy Policy**
|
||||||
|
|
||||||
|
**Effective Date:** ___ [Date] ___
|
||||||
|
|
||||||
|
**This Data Use and Privacy Policy ("Policy")** describes the data practices of **Midas Technologies LLC** (“Company,” “we,” or “us”) regarding the collection, use, and storage of financial data accessed through public sources, APIs, and web scraping technologies. This Policy applies to all users, clients, and stakeholders of Midas Technologies LLC’s services.
|
||||||
|
|
||||||
|
### 1. **Data Collection and Sources**
|
||||||
|
- **Public Financial Data**: We collect financial data exclusively from publicly accessible sources, such as licensed APIs, financial news websites, economic indicators, and related market data sources.
|
||||||
|
- **Web Scraping**: Where legally permissible, we may utilize web scraping technologies to collect publicly available financial data from online sources relevant to our market analysis and trading strategies.
|
||||||
|
- **API Integration**: We integrate with reputable third-party APIs, to which we have legitimate access, for data that aids in predictive modeling and analytics.
|
||||||
|
|
||||||
|
### 2. **Types of Data Collected**
|
||||||
|
- **Market and Economic Indicators**: Data such as price indices, trading volumes, historical price trends, and economic indicators related to commodities, especially crude oil.
|
||||||
|
- **Sentiment Data**: Aggregated sentiment data from publicly available financial news and reports.
|
||||||
|
- **Analytical Data**: Data generated from our proprietary analysis models, which includes derived insights and trends from collected raw data.
|
||||||
|
|
||||||
|
### 3. **Use of Collected Data**
|
||||||
|
- **Algorithmic Trading**: Data is used to inform and develop our algorithmic trading software, focusing on financial trends, price forecasting, and investment strategies.
|
||||||
|
- **Market Analysis and Insights**: Data collected is analyzed to generate insights into financial trends and market behavior, primarily for crude oil trading purposes.
|
||||||
|
- **Data Storage**: All data is securely stored and used strictly within the confines of our analytical tools and proprietary software to ensure the quality and confidentiality of our predictive algorithms.
|
||||||
|
|
||||||
|
### 4. **Data Security and Access**
|
||||||
|
- **Access Control**: Access to data is limited to authorized personnel only, with strict measures in place to prevent unauthorized access or misuse.
|
||||||
|
- **Encryption and Storage**: We implement industry-standard encryption methods to protect data during transmission and storage. All data is stored in secure servers with regular security assessments.
|
||||||
|
- **Data Integrity**: We ensure the integrity of the data used in our models through regular validation and maintenance of our data sources and storage practices.
|
||||||
|
|
||||||
|
### 5. **Third-Party Data Providers**
|
||||||
|
- We use reputable third-party providers for data access, each of which adheres to legal and industry standards. We maintain agreements with each provider to ensure that our use of their data complies with their terms of service and applicable laws.
|
||||||
|
- **Disclaimer**: Midas Technologies LLC is not responsible for any inaccuracies or limitations of data provided by third-party sources.
|
||||||
|
|
||||||
|
### 6. **Compliance with Legal and Ethical Standards**
|
||||||
|
- **Legal Compliance**: Our data collection practices are conducted in compliance with applicable laws and regulations governing the use of publicly available financial data. Where necessary, we obtain permissions or licenses for data access.
|
||||||
|
- **Ethical Use of Data**: We are committed to ethical data practices. We only collect and use data that is publicly available and refrain from unauthorized data extraction or collection from restricted sources.
|
||||||
|
|
||||||
|
### 7. **User Rights and Transparency**
|
||||||
|
- **Transparency in Data Use**: We maintain transparency with our clients and stakeholders regarding the data sources we use and our analytical methodologies.
|
||||||
|
- **No Personal Data Collected**: Midas Technologies LLC does not collect, handle, or process any personal data. Our data usage is restricted to publicly available financial and economic data only.
|
||||||
|
|
||||||
|
### 8. **Changes to This Policy**
|
||||||
|
- Midas Technologies LLC reserves the right to modify or update this Policy at any time to reflect changes in our data practices. Notice of any significant updates will be provided through our official website or directly to our clients, where applicable.
|
||||||
|
- **Effective Date of Changes**: Any changes will take effect on the date specified in the updated Policy.
|
||||||
|
|
||||||
|
### 9. **Contact Information**
|
||||||
|
For questions or further information regarding our Data Use and Privacy Policy, please contact us at:
|
||||||
|
|
||||||
|
**Midas Technologies LLC**
|
||||||
|
Address: [Business Address]
|
||||||
|
Email: [Contact Email]
|
||||||
|
Phone: [Contact Phone Number]
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
This policy clarifies your responsible use of public financial data, data security measures, and ethical compliance. Let me know if you’d like any additional clauses or adjustments.
|
||||||
@@ -0,0 +1,76 @@
|
|||||||
|
**Disaster Recovery and Business Continuity Plan**
|
||||||
|
|
||||||
|
**Effective Date:** ___ [Date] ___
|
||||||
|
**Issued by:** **Midas Technologies LLC**
|
||||||
|
|
||||||
|
This Disaster Recovery and Business Continuity Plan (“Plan”) outlines the procedures and protocols for **Midas Technologies LLC** to prepare for, respond to, and recover from disruptions, ensuring minimal impact on critical business functions, data integrity, and client services.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 1. **Purpose and Scope**
|
||||||
|
- **Purpose**: The purpose of this Plan is to provide a framework for disaster recovery and business continuity to protect Midas Technologies LLC’s assets, including data, infrastructure, and personnel, and to ensure the swift resumption of critical business functions following a disruption.
|
||||||
|
- **Scope**: This Plan applies to all employees, contractors, and third parties responsible for business operations, technology infrastructure, and data handling at Midas Technologies LLC.
|
||||||
|
|
||||||
|
### 2. **Critical Business Functions**
|
||||||
|
Midas Technologies LLC identifies the following as critical business functions that must be prioritized during recovery efforts:
|
||||||
|
- **Data Integrity and Access**: Ensuring access to trading algorithms, data models, and financial records.
|
||||||
|
- **Client Communications**: Maintaining communication channels with clients and partners to inform them of the status and continuity of services.
|
||||||
|
- **Infrastructure and System Functionality**: Protecting key infrastructure, including servers, applications, and networks required for data analysis and trading operations.
|
||||||
|
|
||||||
|
### 3. **Risk Assessment and Potential Threats**
|
||||||
|
The following potential threats are addressed in this Plan:
|
||||||
|
- **Natural Disasters**: Floods, earthquakes, hurricanes, or other natural events that could disrupt operations.
|
||||||
|
- **Cyber Threats**: Malware, ransomware, phishing attacks, and data breaches that threaten IT systems and data security.
|
||||||
|
- **Power and Network Failures**: Interruptions to power supply or internet connectivity that may impact data access and operational continuity.
|
||||||
|
|
||||||
|
### 4. **Backup and Recovery Protocols**
|
||||||
|
- **Data Backup**: Data is backed up daily and stored on secure, encrypted cloud servers. Weekly full backups are conducted to preserve complete data records.
|
||||||
|
- **Recovery Time Objective (RTO)**: The Company aims to restore critical functions within **24 hours** following a disruption.
|
||||||
|
- **Recovery Point Objective (RPO)**: Midas Technologies LLC aims to ensure data recovery up to the last backup point, typically within **24 hours** of any event.
|
||||||
|
|
||||||
|
### 5. **Communication Plan**
|
||||||
|
- **Internal Communications**: In the event of a disruption, the designated response team will communicate with all employees, providing instructions and updates through email, messaging platforms, or emergency contact numbers.
|
||||||
|
- **Client and Partner Notifications**: Clients and partners will be notified of the disruption, its impact, and the expected timeline for recovery through official communication channels, including email and company website updates.
|
||||||
|
- **Designated Spokesperson**: The COO or another designated leader will serve as the spokesperson responsible for all external communications during a disaster.
|
||||||
|
|
||||||
|
### 6. **Data Protection Measures**
|
||||||
|
- **Data Encryption**: All data, both in transit and at rest, is encrypted using industry-standard protocols to ensure confidentiality and integrity.
|
||||||
|
- **Access Control**: Access to backup and recovery systems is restricted to authorized personnel. Two-factor authentication (2FA) is enabled for all accounts with access to backup data.
|
||||||
|
- **Regular Testing**: Backup systems and recovery protocols are tested semi-annually to validate data integrity and assess recovery capabilities.
|
||||||
|
|
||||||
|
### 7. **Designated Personnel and Responsibilities**
|
||||||
|
- **Disaster Recovery Team**: The Disaster Recovery Team (DRT) is responsible for activating and coordinating the Plan in response to a disruption. Team members include:
|
||||||
|
- **IT Lead**: Manages technical recovery operations, including system restoration, data recovery, and IT support.
|
||||||
|
- **Operations Manager**: Coordinates continuity efforts for business operations and manages communication with clients and partners.
|
||||||
|
- **Compliance Officer**: Ensures that all recovery activities comply with regulatory requirements and maintains documentation of the recovery process.
|
||||||
|
|
||||||
|
### 8. **Testing and Maintenance of the Plan**
|
||||||
|
- **Annual Review**: The Plan is reviewed annually to incorporate any changes in technology, personnel, or business structure.
|
||||||
|
- **Testing**: Disaster recovery simulations are conducted every six months to evaluate and improve response time, efficiency, and overall effectiveness.
|
||||||
|
- **Employee Training**: All employees receive training on their roles and responsibilities under this Plan. Key personnel participate in annual training to reinforce protocols and ensure readiness.
|
||||||
|
|
||||||
|
### 9. **Plan Activation and Execution**
|
||||||
|
- **Plan Activation**: In the event of a qualifying disruption, the DRT will assess the situation and determine whether to activate this Plan. Activation requires approval from the COO or designated authority.
|
||||||
|
- **Execution Phases**:
|
||||||
|
1. **Assessment**: Evaluate the disruption's impact on business functions and determine immediate priorities.
|
||||||
|
2. **Recovery**: Implement data recovery and infrastructure restoration procedures to resume critical functions.
|
||||||
|
3. **Communication**: Notify employees, clients, and partners about the disruption status and recovery progress.
|
||||||
|
4. **Resolution**: Monitor restored functions and ensure all systems are fully operational before closing the incident.
|
||||||
|
|
||||||
|
### 10. **Post-Incident Review**
|
||||||
|
- **Debriefing**: Following the resolution of a disaster or disruption, the DRT will conduct a post-incident review to assess response effectiveness and identify areas for improvement.
|
||||||
|
- **Documentation**: The DRT will document all recovery activities, decisions, and outcomes to provide a basis for future improvements and ensure compliance with regulatory requirements.
|
||||||
|
|
||||||
|
### 11. **Acknowledgment of Disaster Recovery and Business Continuity Plan**
|
||||||
|
- All employees and contractors are required to sign an acknowledgment of this Plan, confirming their understanding of and commitment to following disaster recovery and business continuity protocols.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Acknowledgment of Disaster Recovery and Business Continuity Plan**
|
||||||
|
|
||||||
|
By signing below, I acknowledge that I have read, understand, and agree to comply with the Midas Technologies LLC Disaster Recovery and Business Continuity Plan.
|
||||||
|
|
||||||
|
| **Employee’s Name** | **Signature** | **Date** |
|
||||||
|
|----------------------|---------------|----------|
|
||||||
|
| | | |
|
||||||
|
|
||||||
50
BusinessDocumentation/BusinessPlans/EULA.md
Normal file
50
BusinessDocumentation/BusinessPlans/EULA.md
Normal file
@@ -0,0 +1,50 @@
|
|||||||
|
**End-User License Agreement (EULA)**
|
||||||
|
|
||||||
|
**Effective Date:** ___ [Date] ___
|
||||||
|
**Issued by:** **Midas Technologies LLC**
|
||||||
|
|
||||||
|
This End-User License Agreement (“Agreement” or “EULA”) is a legally binding contract between **Midas Technologies LLC** (the “Licensor”) and you, the end user (the “Licensee” or “User”), governing your use of the Licensor’s proprietary software (the “Software”). By downloading, installing, or using the Software, you agree to the terms of this Agreement. If you do not agree, do not download, install, or use the Software.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 1. **License Grant**
|
||||||
|
- **Limited License**: Midas Technologies LLC grants you a non-exclusive, non-transferable, revocable license to install and use the Software solely for your personal or internal business purposes in accordance with this Agreement.
|
||||||
|
- **Restrictions on Use**: You may not:
|
||||||
|
- Copy, modify, or create derivative works of the Software;
|
||||||
|
- Sell, rent, lease, sublicense, distribute, or transfer the Software;
|
||||||
|
- Reverse engineer, decompile, disassemble, or attempt to derive the source code of the Software;
|
||||||
|
- Use the Software for any unlawful purpose or in violation of any laws or regulations.
|
||||||
|
|
||||||
|
### 2. **Intellectual Property Rights**
|
||||||
|
- **Ownership**: Midas Technologies LLC retains all rights, title, and interest in and to the Software, including all intellectual property rights. The Software is licensed, not sold, to you.
|
||||||
|
- **No Rights to IP**: This Agreement does not grant you any ownership rights or any other interest in the Software’s intellectual property.
|
||||||
|
|
||||||
|
### 3. **Software Updates**
|
||||||
|
- **Automatic Updates**: Midas Technologies LLC may, at its discretion, provide updates, upgrades, patches, or modifications to the Software (“Updates”) to improve or enhance its functionality. Such Updates may be automatically applied without notice.
|
||||||
|
- **Acceptance of Updates**: By using the Software, you agree to receive such Updates and acknowledge that they may affect the functionality of the Software.
|
||||||
|
|
||||||
|
### 4. **User Data and Privacy**
|
||||||
|
- **Data Collection**: The Software may collect certain information about your usage, system interactions, and performance. This data is used for internal analytics to improve the Software’s performance and functionality.
|
||||||
|
- **Privacy Compliance**: Midas Technologies LLC is committed to protecting your privacy and will handle any collected data in accordance with applicable privacy laws and its Privacy Policy, which can be found at [Privacy Policy URL].
|
||||||
|
|
||||||
|
### 5. **Limitations of Liability**
|
||||||
|
- **No Warranty**: The Software is provided “AS IS” without warranties of any kind, express or implied, including but not limited to implied warranties of merchantability, fitness for a particular purpose, and non-infringement. Midas Technologies LLC does not warrant that the Software will be error-free, uninterrupted, or compatible with all devices.
|
||||||
|
- **Limitation of Liability**: To the maximum extent permitted by law, Midas Technologies LLC shall not be liable for any indirect, incidental, consequential, or special damages, including but not limited to lost profits, data loss, or business interruption, arising from or related to your use of the Software, even if advised of the possibility of such damages.
|
||||||
|
|
||||||
|
### 6. **Termination**
|
||||||
|
- **Termination by Licensor**: Midas Technologies LLC reserves the right to terminate this Agreement and your access to the Software at any time if you fail to comply with any of its terms.
|
||||||
|
- **Effect of Termination**: Upon termination, you must immediately cease all use of the Software and delete all copies from your systems. Termination does not limit any other rights or remedies available to Midas Technologies LLC under this Agreement or by law.
|
||||||
|
|
||||||
|
### 7. **Governing Law and Jurisdiction**
|
||||||
|
- **Governing Law**: This Agreement shall be governed by the laws of the State of [Your State], without regard to its conflicts of laws principles.
|
||||||
|
- **Jurisdiction**: Any disputes arising out of or related to this Agreement or the Software shall be resolved in the courts of [Your State], and you consent to the jurisdiction of such courts.
|
||||||
|
|
||||||
|
### 8. **Entire Agreement**
|
||||||
|
- This Agreement constitutes the entire agreement between you and Midas Technologies LLC regarding your use of the Software, superseding any prior agreements or understandings, written or oral, related to its subject matter.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Acknowledgment of EULA**
|
||||||
|
|
||||||
|
By installing or using the Software, you acknowledge that you have read, understood, and agree to be bound by this End-User License Agreement.
|
||||||
|
|
||||||
@@ -0,0 +1,58 @@
|
|||||||
|
**Work-for-Hire or Assignment Agreement**
|
||||||
|
|
||||||
|
**This Work-for-Hire or Assignment Agreement ("Agreement")** is entered into as of ___ [Date] ___, by and between **Midas Technologies LLC** (the “Company”), with its principal place of business at [Business Address], and ___ [Contractor/Employee Name] ___ (the “Contributor”).
|
||||||
|
|
||||||
|
### 1. **Scope of Agreement**
|
||||||
|
- **Purpose**: This Agreement is intended to govern the ownership of all materials, intellectual property, and works created by the Contributor for the Company during the term of engagement.
|
||||||
|
- **Relationship**: The Contributor’s relationship with the Company is one of [Employment/Independent Contractor], and nothing in this Agreement is intended to create an employer-employee relationship if the Contributor is engaged as an independent contractor.
|
||||||
|
|
||||||
|
### 2. **Work-for-Hire Provision**
|
||||||
|
- **Work Made for Hire**: All work products, including but not limited to software code, designs, models, data analyses, algorithms, inventions, and any other deliverables (collectively, the “Work Product”), created by the Contributor within the scope of their engagement with the Company shall be considered “work made for hire” as defined under U.S. copyright law.
|
||||||
|
- **Assignment of Rights**: If any part of the Work Product is found not to qualify as a “work made for hire,” the Contributor hereby irrevocably assigns to the Company all rights, title, and interest in and to the Work Product, including all copyrights, patents, trade secrets, and other proprietary rights.
|
||||||
|
|
||||||
|
### 3. **Intellectual Property Rights**
|
||||||
|
- **Assignment of Inventions**: The Contributor agrees to promptly disclose to the Company any inventions, discoveries, or improvements developed in connection with their work for the Company. All such inventions and improvements shall be the exclusive property of the Company.
|
||||||
|
- **Moral Rights Waiver**: To the extent permitted by law, the Contributor waives any moral rights in the Work Product, including the right to attribution and the right to prevent modifications.
|
||||||
|
|
||||||
|
### 4. **Confidentiality and Non-Disclosure**
|
||||||
|
- **Confidential Information**: The Contributor agrees to keep confidential all proprietary information obtained during the course of their engagement, including but not limited to algorithms, trading strategies, client lists, and technical data.
|
||||||
|
- **Non-Disclosure**: The Contributor shall not disclose or use any confidential information for personal gain or for the benefit of any third party, both during and after the term of engagement.
|
||||||
|
|
||||||
|
### 5. **Return of Materials**
|
||||||
|
- Upon termination of the Contributor’s engagement, or upon request by the Company, the Contributor agrees to return all Company property and materials, including any copies of confidential or proprietary information.
|
||||||
|
|
||||||
|
### 6. **Representations and Warranties**
|
||||||
|
- **Original Work**: The Contributor represents and warrants that all Work Product is original, does not infringe upon any third-party rights, and that the Contributor has the full authority to assign all rights in the Work Product to the Company.
|
||||||
|
- **No Conflicting Agreements**: The Contributor represents that they are not subject to any conflicting agreements that would interfere with their ability to perform under this Agreement or assign rights to the Company.
|
||||||
|
|
||||||
|
### 7. **Indemnification**
|
||||||
|
- The Contributor agrees to indemnify and hold the Company harmless from any claims, damages, or expenses arising out of any breach of the representations and warranties provided in this Agreement.
|
||||||
|
|
||||||
|
### 8. **No Additional Compensation**
|
||||||
|
- Unless otherwise agreed upon in writing, the Contributor acknowledges that they will not receive any royalties, residuals, or other compensation related to the use of the Work Product beyond the compensation agreed upon for their services.
|
||||||
|
|
||||||
|
### 9. **Term and Termination**
|
||||||
|
- **Term**: This Agreement shall remain in effect for the duration of the Contributor’s engagement with the Company.
|
||||||
|
- **Survival**: The confidentiality and IP assignment provisions shall survive the termination of this Agreement and the Contributor’s engagement.
|
||||||
|
|
||||||
|
### 10. **Governing Law**
|
||||||
|
- This Agreement shall be governed by and construed in accordance with the laws of the State of [Your State].
|
||||||
|
|
||||||
|
### 11. **Entire Agreement**
|
||||||
|
- This Agreement constitutes the entire understanding between the parties regarding the subject matter hereof and supersedes all prior agreements, understandings, or representations.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Signatures:**
|
||||||
|
|
||||||
|
**Contributor (Employee/Contractor):**
|
||||||
|
___ [Contributor Name] ___
|
||||||
|
Signature: ___________________________
|
||||||
|
Date: ___
|
||||||
|
|
||||||
|
**Midas Technologies LLC:**
|
||||||
|
By: ___ [Authorized Representative Name] ___
|
||||||
|
Title: ___________________________
|
||||||
|
Signature: ___________________________
|
||||||
|
Date: ___
|
||||||
|
|
||||||
73
BusinessDocumentation/BusinessPlans/EmployeeHandbook.md
Normal file
73
BusinessDocumentation/BusinessPlans/EmployeeHandbook.md
Normal file
@@ -0,0 +1,73 @@
|
|||||||
|
**Employee Handbook**
|
||||||
|
|
||||||
|
**Issued by:** **Midas Technologies LLC**
|
||||||
|
**Effective Date:** ___ [Date] ___
|
||||||
|
|
||||||
|
Welcome to **Midas Technologies LLC**! We are excited to have you as part of our team. This Employee Handbook provides guidelines on our values, workplace policies, and procedures to ensure a positive, safe, and compliant work environment. Please read it carefully, as it contains important information about your rights and responsibilities.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Table of Contents
|
||||||
|
1. **Company Values**
|
||||||
|
2. **Code of Conduct**
|
||||||
|
3. **Intellectual Property Ownership**
|
||||||
|
4. **Confidentiality and Data Protection**
|
||||||
|
5. **Anti-Harassment and Equal Employment Opportunity Policy**
|
||||||
|
6. **Benefits and Compensation**
|
||||||
|
7. **Leave and Time-Off Policies**
|
||||||
|
8. **Acknowledgment of Receipt**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 1. **Company Values**
|
||||||
|
- **Innovation**: We prioritize creating leading-edge solutions through creativity and technological excellence.
|
||||||
|
- **Integrity**: Integrity drives our interactions with each other, clients, and partners. Ethical conduct is expected in all business dealings.
|
||||||
|
- **Collaboration**: We succeed through teamwork, open communication, and shared goals. Mutual respect and support are essential to our culture.
|
||||||
|
- **Continuous Learning**: We encourage personal and professional growth through training, mentoring, and development opportunities.
|
||||||
|
|
||||||
|
### 2. **Code of Conduct**
|
||||||
|
- **Professionalism**: Employees are expected to act professionally, respectfully, and ethically toward colleagues, clients, and partners at all times.
|
||||||
|
- **Attendance and Punctuality**: Regular attendance and punctuality are essential. Please notify your manager if you will be absent or late.
|
||||||
|
- **Conflict of Interest**: Employees must avoid any conflicts of interest and disclose any potential conflicts to management.
|
||||||
|
- **Workplace Safety**: Maintain a safe and healthy work environment by following all safety protocols and reporting hazards immediately.
|
||||||
|
|
||||||
|
### 3. **Intellectual Property Ownership**
|
||||||
|
- **Company Ownership**: All intellectual property (IP), including inventions, designs, software, and processes created by employees during employment, are the exclusive property of Midas Technologies LLC.
|
||||||
|
- **Work-for-Hire**: Any work created by employees for the Company is considered "work made for hire" under copyright law and is owned by the Company.
|
||||||
|
- **Invention Disclosure**: Employees must promptly disclose any IP created in the course of their work to their manager or the Company’s legal representative.
|
||||||
|
|
||||||
|
### 4. **Confidentiality and Data Protection**
|
||||||
|
- **Confidential Information**: Employees are required to maintain confidentiality regarding proprietary information, including software code, data models, client information, and trade secrets.
|
||||||
|
- **Data Security**: Employees must follow company policies on data protection, ensuring secure handling and storage of sensitive information.
|
||||||
|
- **Non-Disclosure Agreement (NDA)**: All employees are required to sign an NDA, which remains in effect both during and after employment.
|
||||||
|
|
||||||
|
### 5. **Anti-Harassment and Equal Employment Opportunity Policy**
|
||||||
|
- **Harassment-Free Workplace**: Midas Technologies LLC is committed to providing a workplace free from harassment, including discrimination based on race, gender, religion, disability, or any other protected characteristic.
|
||||||
|
- **Reporting Harassment**: Employees who experience or witness harassment should report it to HR or a designated manager immediately. All reports will be handled confidentially and with no retaliation.
|
||||||
|
- **Equal Employment Opportunity**: Midas Technologies LLC is an equal-opportunity employer and adheres to all laws governing non-discriminatory employment practices.
|
||||||
|
|
||||||
|
### 6. **Benefits and Compensation**
|
||||||
|
- **Salary and Payment**: Employees are compensated bi-weekly/monthly (as applicable) and will receive their agreed-upon salary based on position and experience.
|
||||||
|
- **Health and Wellness Benefits**: Eligible employees receive health insurance, including medical, dental, and vision coverage.
|
||||||
|
- **Retirement Plan**: The Company offers a [401(k) / retirement savings plan] to assist employees with long-term financial planning.
|
||||||
|
- **Training and Development**: Midas Technologies LLC offers ongoing training programs and encourages participation in external workshops and courses relevant to employee roles.
|
||||||
|
|
||||||
|
### 7. **Leave and Time-Off Policies**
|
||||||
|
- **Paid Time Off (PTO)**: Employees accrue PTO based on their length of employment. PTO must be scheduled in advance and approved by a manager.
|
||||||
|
- **Sick Leave**: Paid sick leave is provided for health-related absences. Employees are encouraged to stay home if ill and notify their supervisor as soon as possible.
|
||||||
|
- **Parental Leave**: The Company offers parental leave in accordance with applicable laws.
|
||||||
|
- **Unpaid Leave**: Additional unpaid leave may be granted at the Company’s discretion based on circumstances.
|
||||||
|
|
||||||
|
### 8. **Acknowledgment of Receipt**
|
||||||
|
- All employees are required to sign an acknowledgment form upon receiving this Handbook, confirming they understand and agree to adhere to these policies and standards.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Acknowledgment of Receipt**
|
||||||
|
|
||||||
|
By signing below, I acknowledge that I have received, read, and understand the Midas Technologies LLC Employee Handbook. I agree to adhere to the policies, standards, and expectations outlined in this Handbook.
|
||||||
|
|
||||||
|
| **Employee’s Name** | **Signature** | **Date** |
|
||||||
|
|----------------------|---------------|----------|
|
||||||
|
| | | |
|
||||||
|
|
||||||
184
BusinessDocumentation/BusinessPlans/ExecutiveSummary.md
Normal file
184
BusinessDocumentation/BusinessPlans/ExecutiveSummary.md
Normal file
@@ -0,0 +1,184 @@
|
|||||||
|
# MIDAS TECHNOLOGIES: Executive Summary
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Table of Contents
|
||||||
|
1. [Mission Statement](#mission-statement)
|
||||||
|
2. [Business Model](#business-model)
|
||||||
|
3. [Technology Overview](#technology-overview)
|
||||||
|
- [Price Prediction Models](#price-prediction-models)
|
||||||
|
- [Market Importance Ranking](#market-importance-ranking)
|
||||||
|
4. [Roles and Responsibilities](#roles-and-responsibilities)
|
||||||
|
5. [Comprehensive Technology Roadmap](#comprehensive-technology-roadmap)
|
||||||
|
- [Stage 1: Architecture and Modularity](#stage-1-architecture-and-modularity)
|
||||||
|
- [Stage 2: Data Acquisition and Expansion](#stage-2-data-acquisition-and-expansion)
|
||||||
|
- [Stage 3: Model Development and Complexity Expansion](#stage-3-model-development-and-complexity-expansion)
|
||||||
|
- [Stage 4: Risk Management and Hedging](#stage-4-risk-management-and-hedging)
|
||||||
|
- [Stage 5: Scalability and Live Trading Infrastructure](#stage-5-scalability-and-live-trading-infrastructure)
|
||||||
|
6. [Implementation Pathway](#implementation-pathway)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Mission Statement
|
||||||
|
|
||||||
|
The mission of **Midas Technologies** is to develop algorithmic investment software designed to continuously build a diversified portfolio of algorithmic trading strategies, delivering above-market returns on a consistent basis.
|
||||||
|
|
||||||
|
## Business Model
|
||||||
|
|
||||||
|
Our initial product will be an **algorithmic trading system** focused on predicting and trading the price of crude oil. This Python-based algorithm is engineered to meet specific weekly return and risk benchmarks, using a combination of technical indicators and market sentiment.
|
||||||
|
|
||||||
|
**Core Requirements**:
|
||||||
|
- The algorithm will only be utilized for live trading once it consistently achieves a **60% win rate or higher**.
|
||||||
|
- All trades are informed by a robust analysis of technical indicators and proprietary sentiment metrics.
|
||||||
|
|
||||||
|
## Technology Overview
|
||||||
|
|
||||||
|
### Price Prediction Models
|
||||||
|
|
||||||
|
1. **Speculative Indicators**: Functions that analyze speculative variables, such as news articles, and forecast oil price shifts based on sentiment.
|
||||||
|
- **Objective**: Each indicator outputs a dollar-based price prediction for the following day.
|
||||||
|
|
||||||
|
2. **Economic Indicators**: Functions analyzing macroeconomic relationships, including GDP, supply, demand, and currency fluctuations.
|
||||||
|
- **Objective**: Each indicator provides a forecasted price for the next trading day based on economic trends.
|
||||||
|
|
||||||
|
3. **Weighted Price Prediction Formula**:
|
||||||
|
- The model will consolidate individual indicator predictions into a weighted average to produce an overall prediction.
|
||||||
|
- Each indicator’s weight represents its market relevance, with weights optimized to minimize prediction error.
|
||||||
|
- **Formula**:
|
||||||
|
```
|
||||||
|
PriceTomorrow = PriceNews * (w1) + PriceSupply * (w2) + PriceDemand * (w3) + ...
|
||||||
|
```
|
||||||
|
- These weights, continuously refined through backtesting, are foundational to the accuracy of our predictions.
|
||||||
|
|
||||||
|
### Market Importance Ranking
|
||||||
|
- Our system will use optimization algorithms to dynamically adjust indicator weights, ensuring accuracy and adapting to market conditions.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Roles and Responsibilities
|
||||||
|
|
||||||
|
### Board of Directors
|
||||||
|
|
||||||
|
- **Jacob Mardian**
|
||||||
|
- **Equity**: 33.33%
|
||||||
|
- **Role**: Business Operations
|
||||||
|
- **Responsibilities**: Business paperwork, research, trading strategy development, coding the trading bot.
|
||||||
|
|
||||||
|
- **Griffin Witt**
|
||||||
|
- **Equity**: 33.33%
|
||||||
|
- **Role**: Chief of Economic Analysis
|
||||||
|
- **Responsibilities**: Building the intrinsic valuation system, identifying relationships among economic indicators to forecast oil prices.
|
||||||
|
|
||||||
|
- **Collin Schaufele**
|
||||||
|
- **Equity**: 33.33%
|
||||||
|
- **Role**: Chief of Speculative Analysis
|
||||||
|
- **Responsibilities**: Developing models to estimate oil prices based on speculative indicators, licensing and compliance.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Comprehensive Technology Roadmap
|
||||||
|
|
||||||
|
This roadmap outlines a progressive pathway for developing Midas Technologies’ trading platform, expanding from a basic algorithm to a hedge-fund-grade system.
|
||||||
|
|
||||||
|
### Stage 1: Architecture and Modularity
|
||||||
|
|
||||||
|
1. **Core Design**: Begin by modularizing existing code, creating independent components for scalability and flexibility.
|
||||||
|
2. **Modularization Plan**:
|
||||||
|
- **Data Acquisition Module**: API integration for historical and real-time market data.
|
||||||
|
- **Signal Generation Module**: Incorporates technical indicators (e.g., Moving Average, RSI) for easy strategy updates.
|
||||||
|
- **Optimization Module**: Finds optimal strategy weights for maximum performance.
|
||||||
|
- **Backtesting Module**: Analyzes historical data, providing profit/loss, Sharpe ratio, and win rate metrics.
|
||||||
|
- **Risk Management Module**: Manages position sizing, drawdown limits, and hedging.
|
||||||
|
- **Execution Module**: Handles broker integration and trade execution.
|
||||||
|
- **Reporting Module**: Generates detailed reports in PDF, Excel, or HTML formats post-backtesting or trading.
|
||||||
|
|
||||||
|
**Example (Python)**:
|
||||||
|
```python
|
||||||
|
class DataAcquisition:
|
||||||
|
def __init__(self, ticker):
|
||||||
|
self.ticker = ticker
|
||||||
|
|
||||||
|
def fetch_price_data(self, start_date, end_date):
|
||||||
|
"""Fetch historical price data"""
|
||||||
|
data = yf.download(self.ticker, start=start_date, end=end_date)
|
||||||
|
return data
|
||||||
|
```
|
||||||
|
|
||||||
|
### Stage 2: Data Acquisition and Expansion
|
||||||
|
|
||||||
|
1. **Data Sources**:
|
||||||
|
- **Yahoo Finance**: Initial data source.
|
||||||
|
- **IEX Cloud, Alpha Vantage**: High-frequency trading data.
|
||||||
|
- **Quandl, CBOE**: Options and market sentiment data.
|
||||||
|
- **Alternative Data**: Social sentiment, satellite data for supply analysis.
|
||||||
|
|
||||||
|
2. **Data Preprocessing**: Handle missing values and normalize across data sources.
|
||||||
|
|
||||||
|
**Example**:
|
||||||
|
```python
|
||||||
|
def preprocess_data(data):
|
||||||
|
data.fillna(method='ffill', inplace=True)
|
||||||
|
data['returns'] = data['Close'].pct_change()
|
||||||
|
return data
|
||||||
|
```
|
||||||
|
|
||||||
|
### Stage 3: Model Development and Complexity Expansion
|
||||||
|
|
||||||
|
1. **Advanced Technical Indicators**:
|
||||||
|
- Integrate multi-timeframe analysis (daily, weekly, monthly).
|
||||||
|
- Use advanced indicators like MACD, ADX, and Fibonacci Retracement.
|
||||||
|
|
||||||
|
2. **Machine Learning for Signal Prediction**:
|
||||||
|
- **Random Forests** and **Reinforcement Learning** to enhance signal prediction.
|
||||||
|
|
||||||
|
**Example (Random Forest)**:
|
||||||
|
```python
|
||||||
|
from sklearn.ensemble import RandomForestClassifier
|
||||||
|
def train_model(data):
|
||||||
|
X = data[['MA', 'RSI', 'Bollinger_Bands']]
|
||||||
|
y = data['buy_sell_signal']
|
||||||
|
model = RandomForestClassifier(n_estimators=100)
|
||||||
|
model.fit(X, y)
|
||||||
|
return model
|
||||||
|
```
|
||||||
|
|
||||||
|
### Stage 4: Risk Management and Hedging
|
||||||
|
|
||||||
|
1. **Risk Controls**:
|
||||||
|
- Position sizing based on volatility and drawdown limits.
|
||||||
|
- Dynamic stop-loss and take-profit settings.
|
||||||
|
|
||||||
|
2. **Hedging Strategies**:
|
||||||
|
- Long/short position hedging using oil futures.
|
||||||
|
- Options strategies like Iron Condors and Bull Call Spreads.
|
||||||
|
|
||||||
|
### Stage 5: Scalability and Live Trading Infrastructure
|
||||||
|
|
||||||
|
1. **Execution Module**:
|
||||||
|
- Real-time broker API integration (Interactive Brokers, Alpaca).
|
||||||
|
- Manage execution risks like slippage.
|
||||||
|
|
||||||
|
2. **Cloud-Based Scalability**:
|
||||||
|
- Deploy on AWS or Google Cloud for scalability.
|
||||||
|
- Use auto-scaling for intensive data processing.
|
||||||
|
|
||||||
|
3. **Advanced Monitoring**:
|
||||||
|
- Real-time dashboards using Plotly Dash.
|
||||||
|
- SMS/email alerts for key trading signals.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Implementation Pathway
|
||||||
|
|
||||||
|
| Stage | Timeline | Key Tasks |
|
||||||
|
|---------------|-------------------------|-------------------------------------------------------------------------------------------------|
|
||||||
|
| Weeks 1-2 | Develop Scraper & Sentiment Analysis | Build news scraper, implement sentiment analysis models. |
|
||||||
|
| Weeks 3-4 | Confidence Scoring, Volatility Module | Add confidence scoring, build pre-market volatility prediction models. |
|
||||||
|
| Weeks 5-6 | Historical Pattern & Technical Analysis | Implement historical pattern matching, integrate technical indicators for analysis confirmation.|
|
||||||
|
| Weeks 7-8 | Trade Execution and Decision Modules | Develop modules for trade execution, options selection, and risk management. |
|
||||||
|
| Weeks 9-10 | Monitoring and Real-Time Adjustments | Real-time tracking, set up alert systems, finalize dashboards. |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
Through this phased approach, Midas Technologies will evolve its algorithmic trading platform to a sophisticated system with robust data processing, advanced modeling, and real-time trading capabilities.
|
||||||
|
```
|
||||||
@@ -0,0 +1,51 @@
|
|||||||
|
**Intellectual Property Assignment Agreement**
|
||||||
|
|
||||||
|
**This Intellectual Property Assignment Agreement ("Agreement")** is made and entered into as of ___ [Date] ___, by and between **Midas Technologies LLC** (the “Company”), and ___ [Creator Name] ___ (the “Assignor”).
|
||||||
|
|
||||||
|
**1. Definitions**
|
||||||
|
- **Intellectual Property (IP)**: For the purposes of this Agreement, “Intellectual Property” includes, but is not limited to, all software, source code, algorithms, models, data sets, inventions, processes, methodologies, improvements, trade secrets, proprietary information, designs, works of authorship, documentation, and any other creations developed or created by the Assignor for the Company.
|
||||||
|
- **Work Product**: Any work, product, or IP created by the Assignor related to the Company’s business, including algorithmic trading software, proprietary data models, and technical or economic indicators.
|
||||||
|
|
||||||
|
**2. Assignment of Rights**
|
||||||
|
- **Full Assignment**: Assignor hereby irrevocably assigns to the Company all rights, title, and interest in and to any IP and Work Product developed or created by the Assignor for the Company, whether created solely by the Assignor or with others, effective upon creation. This assignment includes worldwide rights to all patents, copyrights, trademarks, trade secrets, and other IP rights.
|
||||||
|
- **Moral Rights Waiver**: Assignor waives all moral rights in the IP and Work Product, including the right to attribution and the right to prevent modification, to the extent allowed by law.
|
||||||
|
|
||||||
|
**3. Representations and Warranties**
|
||||||
|
- **Original Work**: Assignor represents that all IP and Work Product is original and does not infringe upon any third-party IP rights.
|
||||||
|
- **Non-infringement**: Assignor warrants that the IP is free from any claims, encumbrances, or liens and that Assignor has the full authority to assign these rights.
|
||||||
|
- **Third-Party Contributions**: If any third-party IP is incorporated, Assignor shall obtain written approval from the Company and provide all necessary licenses or releases to the Company.
|
||||||
|
|
||||||
|
**4. Confidentiality**
|
||||||
|
- Assignor agrees to maintain strict confidentiality regarding all IP and proprietary information related to the Company’s business, including but not limited to trade secrets, algorithms, and data models, and shall not disclose or use such information except as authorized by the Company.
|
||||||
|
|
||||||
|
**5. Further Assurances**
|
||||||
|
- Assignor agrees to execute any documents and take any actions reasonably requested by the Company to further document or perfect the assignment of rights, including filing for patents or other IP protections.
|
||||||
|
|
||||||
|
**6. No Royalties or Additional Compensation**
|
||||||
|
- The assignment of IP rights under this Agreement is made without expectation of additional compensation beyond any payment or remuneration agreed upon between the Company and the Assignor under separate agreements. Assignor agrees that the Company will own the IP outright, with no obligation to pay royalties or any other compensation.
|
||||||
|
|
||||||
|
**7. Term and Termination**
|
||||||
|
- **Term**: This Agreement remains in effect for as long as Assignor is employed by or contracted with the Company.
|
||||||
|
- **Survival**: The confidentiality and IP ownership provisions of this Agreement shall survive termination of Assignor’s relationship with the Company.
|
||||||
|
|
||||||
|
**8. Governing Law**
|
||||||
|
- This Agreement shall be governed by and construed in accordance with the laws of the State of [Your State].
|
||||||
|
|
||||||
|
**9. Entire Agreement**
|
||||||
|
- This Agreement constitutes the entire understanding between the parties regarding the subject matter and supersedes all prior agreements, discussions, or representations.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Signatures:**
|
||||||
|
|
||||||
|
**Assignor:**
|
||||||
|
___ [Assignor Name] ___
|
||||||
|
Signature: ___________________________
|
||||||
|
Date: ___
|
||||||
|
|
||||||
|
**Midas Technologies LLC:**
|
||||||
|
By: ___ [Authorized Representative Name] ___
|
||||||
|
Title: ___________________________
|
||||||
|
Signature: ___________________________
|
||||||
|
Date: ___
|
||||||
|
|
||||||
@@ -0,0 +1,55 @@
|
|||||||
|
**Non-Compete and Non-Solicitation Agreement**
|
||||||
|
|
||||||
|
**This Non-Compete and Non-Solicitation Agreement ("Agreement")** is entered into as of ___ [Date] ___, by and between **Midas Technologies LLC** (the “Company”), and ___ [Employee/Contractor Name] ___ (the “Employee”).
|
||||||
|
|
||||||
|
**1. Definitions**
|
||||||
|
- **Restricted Activities**: Includes the development, marketing, or sale of algorithmic trading software or any products or services substantially similar to those developed, marketed, or offered by the Company.
|
||||||
|
- **Restricted Area**: The geographic and virtual territories where the Company conducts business, including any online or digital marketplaces.
|
||||||
|
|
||||||
|
**2. Non-Competition Covenant**
|
||||||
|
- **Agreement Not to Compete**: During the term of Employee’s engagement with the Company and for a period of **[1-2 years]** after termination of engagement, the Employee shall not, directly or indirectly, engage in any business or activity that competes with the Company’s business, either independently or as an employee, partner, consultant, or shareholder, within the Restricted Area.
|
||||||
|
- **Scope of Restricted Activities**: This restriction specifically includes the development of any trading software, algorithms, or related products that would reasonably compete with the proprietary offerings of the Company.
|
||||||
|
|
||||||
|
**3. Non-Solicitation of Employees**
|
||||||
|
- **Agreement Not to Solicit Employees**: For a period of **[1-2 years]** following termination of employment or engagement, the Employee shall not, directly or indirectly, solicit or attempt to solicit any of the Company’s employees, consultants, or independent contractors to leave their employment or engagement with the Company.
|
||||||
|
|
||||||
|
**4. Non-Solicitation of Clients and Partners**
|
||||||
|
- **Agreement Not to Solicit Clients**: Employee agrees not to solicit, divert, or attempt to solicit or divert any clients, partners, or prospective clients or partners of the Company with whom the Employee had material contact during the last **12 months** of employment or engagement, for a period of **[1-2 years]** following termination of engagement.
|
||||||
|
- **Definition of Material Contact**: “Material Contact” includes any direct interaction with clients or partners for the purpose of conducting business on behalf of the Company.
|
||||||
|
|
||||||
|
**5. Confidentiality and Protection of Proprietary Information**
|
||||||
|
- **Confidentiality Obligation**: Employee shall maintain strict confidentiality regarding the Company’s trade secrets, proprietary information, and client information, both during and after the term of engagement. This includes, but is not limited to, information regarding the Company’s algorithms, trading strategies, and data models.
|
||||||
|
- **Return of Property**: Upon termination of engagement, Employee agrees to return all Company property, documents, and electronic data in their possession.
|
||||||
|
|
||||||
|
**6. Acknowledgment of Reasonableness**
|
||||||
|
- Employee acknowledges that the restrictions in this Agreement are reasonable and necessary to protect the Company’s legitimate business interests, including the protection of confidential information, client relationships, and the integrity of the Company’s proprietary technology.
|
||||||
|
- **Independent Covenants**: The covenants in this Agreement are independent and enforceable independently of any other terms of employment or engagement.
|
||||||
|
|
||||||
|
**7. Remedies**
|
||||||
|
- **Injunctive Relief**: Employee acknowledges that a breach of this Agreement will result in irreparable harm to the Company for which monetary damages may be inadequate. Accordingly, the Company is entitled to seek injunctive relief in addition to any other remedies it may have under law or equity.
|
||||||
|
- **Recovery of Costs**: In the event of a breach, the Employee shall be liable for all reasonable legal costs and fees incurred by the Company in enforcing this Agreement.
|
||||||
|
|
||||||
|
**8. Governing Law and Jurisdiction**
|
||||||
|
- This Agreement shall be governed by and construed in accordance with the laws of the State of [Your State], and any disputes arising out of this Agreement shall be resolved in the courts located within [Your State].
|
||||||
|
|
||||||
|
**9. Severability**
|
||||||
|
- If any provision of this Agreement is held to be invalid or unenforceable, the remaining provisions shall continue in full force and effect.
|
||||||
|
|
||||||
|
**10. Entire Agreement**
|
||||||
|
- This Agreement constitutes the entire agreement between the parties concerning non-competition, non-solicitation, and confidentiality and supersedes all prior agreements, discussions, or representations.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Signatures:**
|
||||||
|
|
||||||
|
**Employee/Contractor:**
|
||||||
|
___ [Employee/Contractor Name] ___
|
||||||
|
Signature: ___________________________
|
||||||
|
Date: ___
|
||||||
|
|
||||||
|
**Midas Technologies LLC:**
|
||||||
|
By: ___ [Authorized Representative Name] ___
|
||||||
|
Title: ___________________________
|
||||||
|
Signature: ___________________________
|
||||||
|
Date: ___
|
||||||
|
|
||||||
66
BusinessDocumentation/BusinessPlans/OperatingAgreement.md
Normal file
66
BusinessDocumentation/BusinessPlans/OperatingAgreement.md
Normal file
@@ -0,0 +1,66 @@
|
|||||||
|
**Operating Agreement of Midas Technologies LLC**
|
||||||
|
|
||||||
|
**This Operating Agreement ("Agreement")** is made and entered into as of this ___ day of ___, 2024, by and among the following members (the "Members"):
|
||||||
|
|
||||||
|
| **Member Name** | **Ownership Percentage** |
|
||||||
|
|----------------------|--------------------------|
|
||||||
|
| Jacob Mardian | 33.33% |
|
||||||
|
| Griffin Witt | 33.33% |
|
||||||
|
| Collin Schaufele | 33.33% |
|
||||||
|
|
||||||
|
**Article I: Formation and Purpose**
|
||||||
|
1. **Formation**: Midas Technologies LLC ("Company") is formed as a limited liability company under the laws of the State of Virginia.
|
||||||
|
2. **Principal Office**: The Company’s principal place of business is located at [Business Address].
|
||||||
|
3. **Purpose**: The primary purpose of the Company is to develop, maintain, and commercialize algorithmic trading software and related technology.
|
||||||
|
|
||||||
|
**Article II: Capital Contributions**
|
||||||
|
1. **Initial Contributions**: Each Member agrees to make an initial capital contribution as outlined below, in cash or in-kind, and any additional contributions shall be made only upon the unanimous consent of the Members.
|
||||||
|
2. **Ownership Interest**: The ownership percentage of each Member shall be determined by the amount of their initial contribution and as detailed above.
|
||||||
|
|
||||||
|
**Article III: Management and Voting Rights**
|
||||||
|
1. **Management Structure**: The Company shall be managed by the Members, who shall make all major decisions by majority or unanimous vote, as specified herein.
|
||||||
|
2. **Voting Rights**: Each Member holds a voting right proportionate to their ownership percentage. Decisions regarding the sale of the Company or other major changes require unanimous consent.
|
||||||
|
3. **Meetings**: Meetings shall be held at least once annually, and decisions may be taken at such meetings or by written consent. Meetings may be held virtually if agreed by all Members.
|
||||||
|
|
||||||
|
**Article IV: Roles and Responsibilities**
|
||||||
|
1. **Jacob Mardian**: Responsible for business operations, strategy development, and software coding for trading algorithms.
|
||||||
|
2. **Griffin Witt**: Oversees economic analysis, focusing on developing intrinsic valuation models and economic indicators.
|
||||||
|
3. **Collin Schaufele**: Manages speculative analysis, including models for oil price estimation and ensuring regulatory compliance.
|
||||||
|
|
||||||
|
**Article V: Distributions and Profit Allocation**
|
||||||
|
1. **Distributions**: Profits shall be distributed annually unless otherwise agreed by the Members. Distributions shall be proportional to each Member’s ownership percentage.
|
||||||
|
2. **Reinvestment**: A portion of profits may be reinvested in the Company for growth and operational needs, as decided by a majority vote.
|
||||||
|
|
||||||
|
**Article VI: Transfer of Interests**
|
||||||
|
1. **Transfer Restrictions**: No Member may transfer their ownership interest without the consent of the other Members. The Company or other Members shall have the first right to purchase any offered interest.
|
||||||
|
2. **Buyout Option**: In the event a Member wishes to exit, the remaining Members have the right to buy out that Member’s interest at fair market value.
|
||||||
|
|
||||||
|
**Article VII: Confidentiality and Intellectual Property**
|
||||||
|
1. **Confidentiality**: Members agree to keep all company information, including algorithms, strategies, and client data, confidential.
|
||||||
|
2. **Intellectual Property**: All intellectual property, including algorithms, trading software, and proprietary data models developed by any Member for the Company, shall be the exclusive property of the Company.
|
||||||
|
|
||||||
|
**Article VIII: Dissolution**
|
||||||
|
1. **Dissolution Events**: The Company may be dissolved upon a unanimous decision by the Members or as required by law.
|
||||||
|
2. **Distribution upon Dissolution**: Upon dissolution, the Company’s assets will be liquidated, and any remaining proceeds, after settling debts, will be distributed to Members in accordance with their ownership percentages.
|
||||||
|
|
||||||
|
**Article IX: Indemnification and Liability**
|
||||||
|
1. **Indemnification**: The Company shall indemnify each Member for actions taken in good faith on behalf of the Company.
|
||||||
|
2. **Liability**: No Member shall be personally liable for the Company’s obligations, except for their capital contributions.
|
||||||
|
|
||||||
|
**Article X: Governing Law**
|
||||||
|
This Agreement shall be governed by and construed in accordance with the laws of the State of [Your State].
|
||||||
|
|
||||||
|
**Article XI: Amendments**
|
||||||
|
Amendments to this Agreement may be made only with the unanimous consent of all Members.
|
||||||
|
|
||||||
|
**Signatures:**
|
||||||
|
|
||||||
|
---
|
||||||
|
**Member Signature:**
|
||||||
|
|
||||||
|
| Name | Date | Signature |
|
||||||
|
|--------------------|--------|--------------------|
|
||||||
|
| Jacob Mardian | | |
|
||||||
|
| Griffin Witt | | |
|
||||||
|
| Collin Schaufele | | |
|
||||||
|
|
||||||
69
BusinessDocumentation/BusinessPlans/PartnershipAgreement.md
Normal file
69
BusinessDocumentation/BusinessPlans/PartnershipAgreement.md
Normal file
@@ -0,0 +1,69 @@
|
|||||||
|
**Partnership Agreement**
|
||||||
|
|
||||||
|
**Effective Date:** ___ [Date] ___
|
||||||
|
**Issued by:** **Midas Technologies LLC** and **[Partner Company/Individual Name]**
|
||||||
|
|
||||||
|
This Partnership Agreement (“Agreement”) is made and entered into by and between **Midas Technologies LLC** (the “Company”), with its principal place of business at [Business Address], and **[Partner Name]** (the “Partner”), with its principal place of business at [Partner’s Business Address]. Together, the Company and the Partner are referred to as the “Parties.”
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 1. **Purpose and Scope of Partnership**
|
||||||
|
- **Purpose**: The purpose of this Agreement is to establish a partnership between the Company and the Partner to [specific purpose, e.g., develop joint technology, share resources, enhance market presence].
|
||||||
|
- **Scope**: This Agreement outlines the responsibilities, revenue-sharing arrangement, intellectual property rights, and other obligations to achieve the partnership's goals effectively.
|
||||||
|
|
||||||
|
### 2. **Roles and Responsibilities**
|
||||||
|
- **Company’s Role**: Midas Technologies LLC agrees to provide [details of resources, technology, expertise, or support the Company will contribute].
|
||||||
|
- **Partner’s Role**: The Partner agrees to contribute [details of resources, technology, market access, or expertise the Partner will provide].
|
||||||
|
- **Decision-Making**: Major decisions impacting the partnership’s goals and financial outcomes shall be made jointly, with each Party having equal say unless otherwise specified.
|
||||||
|
|
||||||
|
### 3. **Revenue Sharing and Financial Contributions**
|
||||||
|
- **Revenue Sharing**: Net profits generated from this partnership will be shared between the Parties based on the following percentages: ___% to Midas Technologies LLC and ___% to [Partner Name].
|
||||||
|
- **Initial Contributions**: Each Party agrees to bear its respective costs for fulfilling the responsibilities outlined in this Agreement, unless otherwise agreed in writing.
|
||||||
|
- **Additional Funding**: If additional funding is required to achieve the partnership’s objectives, contributions shall be discussed and agreed upon by both Parties in writing.
|
||||||
|
|
||||||
|
### 4. **Intellectual Property (IP) Rights**
|
||||||
|
- **Existing IP**: Each Party retains sole ownership of all intellectual property and proprietary information it held prior to entering this Agreement.
|
||||||
|
- **Jointly Developed IP**: Any IP jointly developed through the partnership will be co-owned by both Parties, with equal rights to use and commercialize the jointly developed IP, unless otherwise agreed.
|
||||||
|
- **Licensing Rights**: Each Party grants the other a non-exclusive, royalty-free license to use its pre-existing IP solely for the purpose of fulfilling the objectives of this partnership. This license shall terminate upon termination of this Agreement.
|
||||||
|
|
||||||
|
### 5. **Confidentiality and Non-Disclosure**
|
||||||
|
- **Confidential Information**: Both Parties agree to keep confidential all proprietary and sensitive information shared in the course of the partnership, including but not limited to business strategies, trade secrets, client lists, and technical know-how.
|
||||||
|
- **Non-Disclosure Obligations**: Confidential information must not be disclosed to any third parties without the prior written consent of the disclosing Party. This obligation survives the termination of this Agreement.
|
||||||
|
- **Return of Materials**: Upon termination, each Party will return or destroy all confidential information belonging to the other Party.
|
||||||
|
|
||||||
|
### 6. **Non-Compete and Non-Solicitation**
|
||||||
|
- **Non-Compete**: During the term of this Agreement and for a period of **[1-2 years]** following termination, neither Party shall engage in any activities that directly compete with the purpose of this partnership within the specified markets, without prior written consent from the other Party.
|
||||||
|
- **Non-Solicitation**: Neither Party shall solicit or hire employees, contractors, or clients of the other Party during the term of this Agreement and for **[1-2 years]** thereafter, unless mutually agreed.
|
||||||
|
|
||||||
|
### 7. **Term and Termination**
|
||||||
|
- **Term**: This Agreement shall be effective as of the date first written above and shall continue for a period of ___ [Term Length, e.g., 2 years], unless terminated earlier as provided herein.
|
||||||
|
- **Termination for Cause**: Either Party may terminate this Agreement immediately upon written notice if the other Party breaches any material term and fails to cure such breach within 30 days of receiving notice.
|
||||||
|
- **Termination by Mutual Agreement**: This Agreement may also be terminated by mutual consent of both Parties.
|
||||||
|
|
||||||
|
### 8. **Dispute Resolution**
|
||||||
|
- **Good Faith Negotiation**: The Parties agree to attempt to resolve any disputes arising from this Agreement through good-faith negotiations.
|
||||||
|
- **Mediation/Arbitration**: If a dispute cannot be resolved through negotiation, the Parties agree to seek resolution through [mediation/arbitration] before resorting to litigation.
|
||||||
|
- **Governing Law and Jurisdiction**: This Agreement shall be governed by the laws of the State of [Your State], and any disputes shall be resolved in the courts located within [Your State].
|
||||||
|
|
||||||
|
### 9. **Amendments**
|
||||||
|
- **Written Amendments Only**: Any amendments or modifications to this Agreement must be in writing and signed by both Parties. Verbal agreements are not binding.
|
||||||
|
|
||||||
|
### 10. **Entire Agreement**
|
||||||
|
- This Agreement represents the entire understanding between the Parties regarding the partnership and supersedes all prior agreements, communications, and understandings, whether written or oral.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Signatures:**
|
||||||
|
|
||||||
|
**Midas Technologies LLC:**
|
||||||
|
By: ___ [Authorized Representative Name] ___
|
||||||
|
Title: ___________________________
|
||||||
|
Signature: ___________________________
|
||||||
|
Date: ___
|
||||||
|
|
||||||
|
**Partner:**
|
||||||
|
By: ___ [Partner’s Name] ___
|
||||||
|
Title: ___________________________
|
||||||
|
Signature: ___________________________
|
||||||
|
Date: ___
|
||||||
|
|
||||||
@@ -0,0 +1,63 @@
|
|||||||
|
**Software Development and Licensing Agreement**
|
||||||
|
|
||||||
|
**This Software Development and Licensing Agreement ("Agreement")** is made as of ___ [Date] ___ by and between **Midas Technologies LLC** (the “Licensor”), with its principal place of business at [Business Address], and ___ [Client/Licensee Name] ___ (the “Licensee”).
|
||||||
|
|
||||||
|
### 1. **Definitions**
|
||||||
|
- **Software**: Refers to the proprietary trading software and related components, including any code, algorithms, data models, and documentation, developed and owned by Licensor.
|
||||||
|
- **License**: A limited, non-exclusive, non-transferable, and revocable right granted to Licensee to use the Software as set forth in this Agreement.
|
||||||
|
|
||||||
|
### 2. **License Grant and Restrictions**
|
||||||
|
- **License Grant**: Subject to the terms and conditions of this Agreement, Licensor grants Licensee a non-exclusive, non-transferable license to use the Software for internal business purposes only.
|
||||||
|
- **License Restrictions**: Licensee shall not:
|
||||||
|
- Copy, modify, adapt, or create derivative works of the Software;
|
||||||
|
- Sell, rent, lease, sublicense, or otherwise distribute the Software to any third party;
|
||||||
|
- Reverse engineer, decompile, disassemble, or otherwise attempt to derive the source code or underlying algorithms of the Software;
|
||||||
|
- Use the Software in any way that competes with or harms the interests of Licensor.
|
||||||
|
|
||||||
|
### 3. **Intellectual Property Rights**
|
||||||
|
- **Ownership**: Licensor retains all rights, title, and interest in and to the Software, including all intellectual property rights. This Agreement does not grant Licensee any ownership rights in the Software.
|
||||||
|
- **Modifications and Improvements**: Any modifications, improvements, or derivative works created by Licensee in connection with the Software are the sole property of Licensor.
|
||||||
|
|
||||||
|
### 4. **Fees and Payment Terms**
|
||||||
|
- **License Fee**: Licensee shall pay Licensor a license fee in the amount of ___ [Fee Amount] ___, payable upon execution of this Agreement or as otherwise specified by Licensor.
|
||||||
|
- **Additional Services**: Any additional customization, support, or development services requested by Licensee will be subject to a separate service fee agreed upon by the parties in writing.
|
||||||
|
|
||||||
|
### 5. **Confidentiality**
|
||||||
|
- **Confidential Information**: Licensee agrees to keep confidential all non-public information related to the Software, including source code, algorithms, and technical documentation, and will not disclose it to any third party without Licensor’s prior written consent.
|
||||||
|
- **Non-Disclosure Obligation**: Licensee’s obligation to protect Confidential Information shall survive the termination of this Agreement.
|
||||||
|
|
||||||
|
### 6. **Warranties and Disclaimers**
|
||||||
|
- **Limited Warranty**: Licensor warrants that it has the right to license the Software and that the Software, as provided, does not infringe upon any third-party intellectual property rights.
|
||||||
|
- **Disclaimer of Warranties**: The Software is provided "AS IS," without any warranties, express or implied, including, but not limited to, implied warranties of merchantability, fitness for a particular purpose, and non-infringement. Licensee assumes all risks associated with the use of the Software.
|
||||||
|
|
||||||
|
### 7. **Limitation of Liability**
|
||||||
|
- **Liability Limitation**: In no event shall Licensor be liable for any direct, indirect, incidental, special, consequential, or punitive damages arising out of or in connection with the use or inability to use the Software, even if Licensor has been advised of the possibility of such damages.
|
||||||
|
|
||||||
|
### 8. **Indemnification**
|
||||||
|
- Licensee agrees to indemnify, defend, and hold Licensor harmless from any claims, damages, or expenses arising out of Licensee’s use of the Software, except to the extent caused by Licensor’s gross negligence or willful misconduct.
|
||||||
|
|
||||||
|
### 9. **Term and Termination**
|
||||||
|
- **Term**: This Agreement shall commence on the date first set forth above and continue for an initial term of ___ [Term Length, e.g., 1 year] ___ unless terminated earlier as provided herein.
|
||||||
|
- **Termination**: Licensor may terminate this Agreement immediately if Licensee breaches any term of this Agreement. Upon termination, Licensee shall immediately cease all use of the Software and return or destroy all copies of the Software in its possession.
|
||||||
|
|
||||||
|
### 10. **Governing Law and Jurisdiction**
|
||||||
|
- This Agreement shall be governed by and construed in accordance with the laws of the State of [Your State]. Any disputes arising out of or related to this Agreement shall be resolved exclusively in the courts located within [Your State].
|
||||||
|
|
||||||
|
### 11. **Entire Agreement and Amendments**
|
||||||
|
- This Agreement constitutes the entire understanding between the parties regarding the subject matter hereof and supersedes all prior agreements, representations, or understandings, whether written or oral. Any amendment or modification of this Agreement must be in writing and signed by both parties.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Signatures:**
|
||||||
|
|
||||||
|
**Midas Technologies LLC (Licensor):**
|
||||||
|
By: ___ [Authorized Representative Name] ___
|
||||||
|
Title: ___________________________
|
||||||
|
Signature: ___________________________
|
||||||
|
Date: ___
|
||||||
|
|
||||||
|
**Licensee:**
|
||||||
|
___ [Licensee Name] ___
|
||||||
|
Signature: ___________________________
|
||||||
|
Date: ___
|
||||||
|
|
||||||
55
BusinessDocumentation/BusinessPlans/TradeSecretPolicy.md
Normal file
55
BusinessDocumentation/BusinessPlans/TradeSecretPolicy.md
Normal file
@@ -0,0 +1,55 @@
|
|||||||
|
**Trade Secret Policy**
|
||||||
|
|
||||||
|
**Effective Date:** ___ [Date] ___
|
||||||
|
**Issued by:** **Midas Technologies LLC**
|
||||||
|
|
||||||
|
**This Trade Secret Policy ("Policy")** outlines the responsibilities, protocols, and procedures of **Midas Technologies LLC** (the "Company") for safeguarding and managing trade secrets and other confidential information critical to the Company’s business success.
|
||||||
|
|
||||||
|
### 1. **Purpose and Scope**
|
||||||
|
- **Purpose**: This Policy aims to protect and maintain the confidentiality of the Company’s trade secrets and other proprietary information, including algorithms, trading models, data analytics, and strategic plans.
|
||||||
|
- **Scope**: This Policy applies to all employees, contractors, consultants, vendors, and any other individuals who may have access to the Company’s trade secrets (“Authorized Persons”).
|
||||||
|
|
||||||
|
### 2. **Definition of Trade Secrets**
|
||||||
|
- **Trade Secrets**: For the purposes of this Policy, “Trade Secrets” refer to any confidential and proprietary information of the Company that provides a competitive advantage, including but not limited to:
|
||||||
|
- Trading algorithms, data models, proprietary software, and technical know-how.
|
||||||
|
- Market analysis, economic indicators, and proprietary research.
|
||||||
|
- Business strategies, client lists, and financial data.
|
||||||
|
|
||||||
|
### 3. **Confidentiality Obligations**
|
||||||
|
- **Non-Disclosure**: Authorized Persons are required to keep all Trade Secrets strictly confidential and must not disclose them to any third party without the Company’s prior written consent.
|
||||||
|
- **Use Limitation**: Trade Secrets shall be used solely for the benefit of the Company and exclusively for tasks related to the Authorized Person’s role. Any unauthorized use is strictly prohibited.
|
||||||
|
|
||||||
|
### 4. **Access Control and Security Measures**
|
||||||
|
- **Access Limitation**: Access to Trade Secrets is limited to Authorized Persons who require such information to fulfill their professional responsibilities. The Company reserves the right to monitor and limit access to Trade Secrets based on role and necessity.
|
||||||
|
- **Security Measures**: The Company employs industry-standard security protocols, including encryption, password protection, and secure storage, to protect Trade Secrets. Authorized Persons are required to follow all security protocols.
|
||||||
|
- **Physical Security**: Where applicable, physical access to documents, servers, and devices containing Trade Secrets is restricted to authorized personnel only.
|
||||||
|
|
||||||
|
### 5. **Employee and Contractor Responsibilities**
|
||||||
|
- **Acknowledgment of Obligations**: All employees, contractors, and vendors must acknowledge and agree to this Policy upon onboarding or contracting with the Company.
|
||||||
|
- **Exit Obligations**: Upon termination of employment or contract, all Authorized Persons must return all Company property, including devices, documents, and files, and certify the deletion of any Trade Secrets stored on personal devices.
|
||||||
|
|
||||||
|
### 6. **Reporting and Addressing Unauthorized Disclosure**
|
||||||
|
- **Duty to Report**: Any Authorized Person who becomes aware of unauthorized access, use, or disclosure of Trade Secrets is required to promptly report it to the Company’s [Designated Officer, e.g., COO].
|
||||||
|
- **Investigative Measures**: The Company will promptly investigate any potential or actual breach of this Policy and may take disciplinary action, including termination or legal action, as appropriate.
|
||||||
|
|
||||||
|
### 7. **Consequences of Policy Violation**
|
||||||
|
- **Disciplinary Action**: Violation of this Policy by employees may result in disciplinary action, up to and including termination of employment or contract.
|
||||||
|
- **Legal Recourse**: The Company reserves the right to pursue legal action, including seeking damages or injunctive relief, against any individual or entity responsible for the unauthorized use or disclosure of Trade Secrets.
|
||||||
|
|
||||||
|
### 8. **Legal Protections**
|
||||||
|
- **State and Federal Laws**: This Policy is designed to comply with applicable state and federal trade secret laws. The Company’s Trade Secrets are protected under the [Your State’s Trade Secret Act] and the Defend Trade Secrets Act (DTSA) where applicable.
|
||||||
|
- **Whistleblower Protections**: In accordance with the DTSA, Authorized Persons are advised that they shall not be held liable for disclosure of Trade Secrets made in confidence to a government official, attorney, or as part of a court filing under seal for the purpose of reporting or investigating a suspected violation of the law.
|
||||||
|
|
||||||
|
### 9. **Policy Acknowledgment**
|
||||||
|
- Each Authorized Person is required to sign an acknowledgment of this Policy, affirming their understanding of and commitment to safeguarding the Company’s Trade Secrets.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Acknowledgment of Trade Secret Policy**
|
||||||
|
|
||||||
|
By signing below, I acknowledge that I have read, understand, and agree to comply with the Midas Technologies LLC Trade Secret Policy. I am aware of the importance of protecting Trade Secrets and understand that failure to comply with this Policy may result in disciplinary or legal action.
|
||||||
|
|
||||||
|
| **Authorized Person’s Name** | **Signature** | **Date** |
|
||||||
|
|-------------------------------|---------------|----------|
|
||||||
|
| | | |
|
||||||
|
|
||||||
117
BusinessDocumentation/BusinessPlans/oil_oracle.md
Normal file
117
BusinessDocumentation/BusinessPlans/oil_oracle.md
Normal file
@@ -0,0 +1,117 @@
|
|||||||
|
# Oil Oracle 1.0 Technology Overview
|
||||||
|
|
||||||
|
## Table of Contents
|
||||||
|
1. [Overview](#overview)
|
||||||
|
2. [Step-by-Step Development](#step-by-step-development)
|
||||||
|
- [Step 1: News Scraper and Sentiment Analysis](#step-1-news-scraper-and-sentiment-analysis)
|
||||||
|
- [Step 2: Confidence Scoring Module](#step-2-confidence-scoring-module)
|
||||||
|
- [Step 3: Pre-Market Volatility Assessment Module](#step-3-pre-market-volatility-assessment-module)
|
||||||
|
- [Step 4: Historical Pattern Matching](#step-4-historical-pattern-matching)
|
||||||
|
- [Step 5: Technical Confirmation through Chart Analysis](#step-5-technical-confirmation-through-chart-analysis)
|
||||||
|
- [Step 6: Trade Execution Decision Module](#step-6-trade-execution-decision-module)
|
||||||
|
- [Step 7: Trade Monitoring and Exit Strategy](#step-7-trade-monitoring-and-exit-strategy)
|
||||||
|
3. [Implementation Timeline](#implementation-timeline)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
The **Oil Oracle 1.0** system is designed to analyze market sentiment, volatility, and technical patterns in real-time to make informed trading decisions. The following step-by-step guide outlines each module of the system, detailing how these components will work together to identify optimal trading opportunities.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Step-by-Step Development
|
||||||
|
|
||||||
|
### Step 1: News Scraper and Sentiment Analysis
|
||||||
|
|
||||||
|
**Objective**: Scrape and analyze relevant oil news to determine market sentiment at 9:29 a.m. EST daily.
|
||||||
|
|
||||||
|
- **Source Selection**: Choose reliable oil news sources (e.g., Bloomberg, Reuters, OilPrice.com).
|
||||||
|
- **Scraping**:
|
||||||
|
- Schedule a web scraper to pull relevant articles daily.
|
||||||
|
- Include robust error handling, using proxies and custom user agents to prevent blocking.
|
||||||
|
- **Sentiment Analysis**:
|
||||||
|
- **Text Preprocessing**: Clean and standardize text data by removing HTML tags, punctuation, and irrelevant symbols.
|
||||||
|
- **NLP Model**: Use a model like BERT to determine sentiment.
|
||||||
|
- Assign -1 for positive and +1 for negative sentiment based on expected price movements.
|
||||||
|
- **Confidence Score**: Output a decimal confidence score to reflect sentiment strength (e.g., -0.8 for strong positive, +0.4 for moderate negative).
|
||||||
|
- **Backtesting**: Validate the model by testing historical oil-related news and price trends.
|
||||||
|
|
||||||
|
### Step 2: Confidence Scoring Module
|
||||||
|
|
||||||
|
**Objective**: Assign confidence scores to sentiment analysis predictions.
|
||||||
|
|
||||||
|
- **Algorithm**:
|
||||||
|
- Use ensemble learning, averaging predictions across multiple NLP models.
|
||||||
|
- Factor in the reliability of news sources and historical impact on oil prices.
|
||||||
|
- **Quality Control**:
|
||||||
|
- Filter out low-confidence predictions below a threshold (e.g., 80%) to reduce false signals.
|
||||||
|
|
||||||
|
### Step 3: Pre-Market Volatility Assessment Module
|
||||||
|
|
||||||
|
**Objective**: Assess potential price movement based on historical patterns and pre-market data.
|
||||||
|
|
||||||
|
- **Volatility Analysis**:
|
||||||
|
- Use volatility indicators like Average True Range (ATR) and options data for implied volatility.
|
||||||
|
- Backtest historical price reactions to similar news events.
|
||||||
|
- **Predictive Model**:
|
||||||
|
- Employ machine learning models (e.g., LSTM, XGBoost) to estimate daily volatility using news strength, previous day’s price action, and economic indicators.
|
||||||
|
- **Output**: Predict intraday price movement in percentage terms to inform profit targets and stop-loss levels.
|
||||||
|
|
||||||
|
### Step 4: Historical Pattern Matching
|
||||||
|
|
||||||
|
**Objective**: Validate analysis by comparing current sentiment and volatility to historical data.
|
||||||
|
|
||||||
|
- **Pattern Matching**:
|
||||||
|
- Build a repository of similar historical news events and their impact on oil prices.
|
||||||
|
- Use clustering algorithms to match patterns and assign a correlation score.
|
||||||
|
- **Thresholds**: Set a minimum correlation requirement to validate trading signals.
|
||||||
|
|
||||||
|
### Step 5: Technical Confirmation through Chart Analysis
|
||||||
|
|
||||||
|
**Objective**: Align technical analysis with sentiment and volatility insights.
|
||||||
|
|
||||||
|
- **Technical Analysis**:
|
||||||
|
- Incorporate indicators like Moving Averages, RSI, and Bollinger Bands, and analyze support/resistance levels.
|
||||||
|
- Set confirmation rules (e.g., positive sentiment aligns with a support bounce).
|
||||||
|
- **Confirmation Logic**:
|
||||||
|
- Only proceed with trades if technical indicators align with sentiment (e.g., RSI reversal confirming bullish sentiment).
|
||||||
|
|
||||||
|
### Step 6: Trade Execution Decision Module
|
||||||
|
|
||||||
|
**Objective**: Use combined insights to make trade decisions and select options contracts.
|
||||||
|
|
||||||
|
- **Price Projection**: Combine sentiment, volatility, historical patterns, and technical confirmation.
|
||||||
|
- **Options Selection**:
|
||||||
|
- Assess risk and profitability using criteria like delta, theta, strike price, and expiration.
|
||||||
|
- **Risk Management**:
|
||||||
|
- Set dynamic stop-loss and take-profit levels based on volatility predictions.
|
||||||
|
|
||||||
|
### Step 7: Trade Monitoring and Exit Strategy
|
||||||
|
|
||||||
|
**Objective**: Monitor ongoing trades and exit based on real-time market conditions.
|
||||||
|
|
||||||
|
- **Monitoring**:
|
||||||
|
- Track real-time sentiment, price movements, and technical indicators.
|
||||||
|
- Set alerts for mid-day sentiment changes or volatility spikes.
|
||||||
|
- **Exit Criteria**:
|
||||||
|
- Profit Target: Sell at a pre-defined profit percentage.
|
||||||
|
- Stop Loss: Exit if a maximum loss threshold is met.
|
||||||
|
- Trend Reversal: Adjust or exit positions if technical indicators show reversals.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Implementation Timeline
|
||||||
|
|
||||||
|
| Week | Task |
|
||||||
|
|------|------|
|
||||||
|
| Weeks 1-2 | Develop news scraper and sentiment analysis system |
|
||||||
|
| Weeks 3-4 | Implement confidence scoring and pre-market volatility module |
|
||||||
|
| Weeks 5-6 | Develop historical pattern matching and technical confirmation modules |
|
||||||
|
| Weeks 7-8 | Build decision-making and trade execution modules |
|
||||||
|
| Weeks 9-10 | Integrate monitoring, alerts, and real-time adjustments |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
This approach will lead to a robust, modular trading system combining real-time data processing, machine learning, and strategic decision-making capabilities.
|
||||||
|
|
||||||
63
BusinessDocumentation/CodingPlans/MidasV1Docs.md
Normal file
63
BusinessDocumentation/CodingPlans/MidasV1Docs.md
Normal file
@@ -0,0 +1,63 @@
|
|||||||
|
# MidasV1 Documentation
|
||||||
|
## General Technical Overview
|
||||||
|
- Written for python.
|
||||||
|
- Needs IBJTS API and JTS running or IB gateway running.
|
||||||
|
- Modular Nature.
|
||||||
|
|
||||||
|
## Workflow / Program Design and Goals.
|
||||||
|
- General: Trading bot for contracts
|
||||||
|
1) Main.py:
|
||||||
|
- program ran by user that starts and controllers the other programs.
|
||||||
|
2) Module 1 - the first barrier.
|
||||||
|
a) Operating System Check:
|
||||||
|
* The first part of the first module that is started by the int main. This first part / function of the first module is in charge of determing the operating system of the device running the program. By default this program will be tailored for linux systems, however, eventually, support for Windows, MacOS, BSD, and possibly illumos systems will be added.
|
||||||
|
b) Dependency Check:
|
||||||
|
* This function of module 1 will ensure that all the necessary dependencies are installed. This can be skeleton code for now as not all dependencies have been discovered or outlined. This will also be ran by int main
|
||||||
|
c) Connectivity Check:
|
||||||
|
* THis last function of module 1 will be called by the int mai as are all the other functions of all future modules. This module is in charge of determining if a secure connection has been established with the JTS or IB gateway program running on the user machine. It will gracefully relay these errors to the user, and determine if these errors are critical to the operation of this program, or can be ignored.
|
||||||
|
d) int main:
|
||||||
|
* This function of module 1 will be the the controller of the rest of the function. This function will be called by main.py and will call all the other functions of module 1 in succession (unless it is better defined to remove the int main and just call each function indivudally through the main.py)
|
||||||
|
3) Module 2 - IBJTS List Petitioner
|
||||||
|
a) Scanner:
|
||||||
|
* This overall module is harder to break down then its predicesor. This function however, should start out by taking the log content loaded by main.py The following values need to be loaded into this program, the specific volume, the net change, percent change, and more later down the line, but we'll focus on the first 3 metrics for now. These default values loaded from the config file (located in a directory called config/ inside of the project root directory - called MidasV1 in src of the entire git repo.) With these loaded values, it should use these values, and call the API to retrieve a list of STOCKS that meet the criteria loaded from the config file. This list should be cached in some way for transfer between modules, and short term storage, but it should not be stored long term if possible.
|
||||||
|
b) Refiner:
|
||||||
|
* This function / general idea of the module is to refine the data further. Here, more config information sent from the main.py which loaded the config file for this program should be sent to the refiner. Here we will refine the list to get rid of items. The first refinement shall be as follows; every item in the list, aka every stock of the list must have its individual share price recorded with it. if this stock price is larger then some value defined by the config file, then remove it from the list. the second refinement is this, but its exact logic needs to be determined through the possible API calls, but each item of the list needs to be flagged to either have possible option contracts, or not. If the item in the list does not have possible option contracts, it shall be removed from the list. The third check is comparing each item or stock's volitility index, and if it is above a value specified from the config file, it is to be removed from the list. The fourth, and currently final refinement, will check the length of the list. This refinement is conditional based on a configuration boolean that is either 1 or 0. if the boolean is false, then this refinement shall not be done, if the boolean is true, this refinement shall take place. This conditional refinement be analyzing the number of items in the overall refined list, and if it is above some value defined by the configuration file, then truncate the list to match the value specified in the config file. After this is done, this information should be packaged into the /tmp/ folder or cached, or stored in some short term manner that allows this refined list to be passed to the next module.
|
||||||
|
4) Module 3 - Stock Information Retrieval
|
||||||
|
a) Load:
|
||||||
|
* This function or idea of this module is as follows. It should load the refined list that was created in module 2. Also it should be passed more configuration information which once again is retrieved from the configuration file.
|
||||||
|
b) Threaded Information Gathering and Cleaning and Choosing a Stratedgy
|
||||||
|
* For each stock of the list, that has gone through refinement, make an indiviudal threaded procress that is responble for doing the following for each item of the list. For each stock, pull information every X minutes (retrieved from the configuration file - but it must be a recognized trading interval), the information requested is the following raw data: datetime (exclude date and time just include the single variable datetime), high, low, close, and volume. In this, if the datetime is not of a recognized trading day (Ie it is the weekend, or it is not between the times 9:30am - 4:00 pm) do not record it. Each thread should record its information to a directory called data inside the root directory, each file should be named in the convetion {stock_name}.{current_date}.json. The pulling of information should only go back 48 hours.
|
||||||
|
* Now based on the raw data, as it comes in, from each threated procress, should increase or decrease a counter, This counter shall be referred to as the Stratedgy Counter. Depending on the raw data, the program should algorithmically determine what indicators are the best to analyze this data for further determance of if the trade is advantagous or not. It should do this for all the information as it comes in, so the counter should change with every new input from each thread, and by the end of all the threads retreiving all the information, the counter should have an indication of what Stratedgy should be used, and that stratedgy should be chosen and passed to the next function of this module.
|
||||||
|
c) Stratedgy Implementation and market determination
|
||||||
|
* after the ideal stratedgy has been decided the indicators of that stratedgy should be calculated by the code, or if more efficient, retrieved from the API. So far there is only 1 stratedgy, which shall be the default stratedgy while we improve the logic of module 3. This stratedgy involves calculating or retrieving the RSI, MACD, ADX, and EMA for each stock in the list. If the values of the RSI, MACD, ADX, or EMA, pass some threshold as defined by the config file, this will indcate market determination. So for instance, an RSI of say > 70 is an indication of a bearish market. An RSI of < 30 indicates a bullish market. MACD, if its above 0 indicates bullish, below 0 indicates a bearish market, ADX is more complicated, but generally has a range of < 20 meaning weak, between 20-25 indicates a weak movement, above 25 indicates strong movement, and if EMA is above share price, this indicates a bearish market, if its below this indcates a bearish market. Each of these indicators and all subsequent indicators will need to be weighted on their supposed affect on the market speculation of the stock / contract option. Each of these indicators, depending on their value,should add to another counter, called market counter, and depending on this value, which shall exist for each stock, each stock shall be determined to be either overall bearish, or overall bullish and a weight should be given to determine how bullish or how bearish they are.
|
||||||
|
* Eventualy it would be becoming to utilize system resources, and continue analysis on the complete list, however, this may be difficult in a first attempt / iteration of the program, and rate limiting may prevent this with our current plan. So there shall be an internal boolean (not needed in config) but this internal bool will be true or false. True means that the entire list will continue to the next module. False means the program should isolate the most bearish stock of the list, and the most bullish of the list. These 2 stock symbols, and any needed info shall be passed onto the next module.
|
||||||
|
5) Module 4 - Option Chain Trading, and Risk Management
|
||||||
|
a) Option Chain Data
|
||||||
|
* For the 2 stocks that are passed, labeled bullish and bearish, each of their option chain data should be pulled for the most recent experation posisble. This list should mainly be focused on the strike price for each contract, and the price of that contract. After retrieving that info for both stocks (again thread it for both of them to do it asyncrhonous and fast), the strike price should be compared to the share price. For the bearish stocks, isolate the closest strike price to share price that is cheaper than the strike price. For bearish, isolate the option contract that is selling above stock price, but is the closest selling above stock price. In the future a mechanism to change these rules based on the datetime is needed, as before 12 AM is normally prime stock market hours, so these rules may need to change depending on the time of the trade.
|
||||||
|
b) Risk Management Stage 1:
|
||||||
|
* After determing the option contracts to buy, the program has to retrieve the account balance information of the user, and determine acceptable risk from the configuration file. Therewill be need to be a variable that is respobsible for this percentage, but if the contract option costs x% or less, then it is deemed as an acceptable risk, and that contract option shall continue for procressing.
|
||||||
|
c) Buying and Selling / Risk Managemnt 2:
|
||||||
|
* At this stage, contract option(s) should be given to this function/section of the fourth module. This contract option(s), if it passed risk management 1, should be bought by the API (with a check to ensure the trade is only on paper). Information should continously be gathered on the bought contract option's stock's raw data as it comes in on a x timely bases (defined by the config file). Additionally, a second contract, a stop contract, should be created for a loss of x% (defined by the configuration file).
|
||||||
|
* From the continous information gathering, a sell stratedgy needs to be developed, much like the buy stratedgy to determine an optimal time to sell the contract after purchasing.
|
||||||
|
6) General Additions:
|
||||||
|
* Add flags to the main.py to run the program with checks, without checks, verbose, etc.
|
||||||
|
* The program should have both print statements and log statements throughout and depending on a flag (verbose or not) the program should log this by default, or if verbose, print everything it would log to the console. Some information needs to be printed instead of logged and there will be some exceptions.
|
||||||
|
|
||||||
|
|
||||||
|
## File Structure
|
||||||
|
* Project Directory / MidasV1:
|
||||||
|
* README.md
|
||||||
|
* requirements.txt
|
||||||
|
* config/
|
||||||
|
* config.config
|
||||||
|
* main.py: main script orchestrating application.
|
||||||
|
* modules/
|
||||||
|
* data_retrieval.py
|
||||||
|
* analysis.py
|
||||||
|
* tradng_execution.py
|
||||||
|
* tests/
|
||||||
|
* test_data_retrieval.py
|
||||||
|
* test_analysis.py
|
||||||
|
* test_trading_execution.py
|
||||||
|
* logs/
|
||||||
|
* MidasV1.log
|
||||||
186
BusinessDocumentation/LegalDocs/MidasTechNologiesLLCBylaws.md
Normal file
186
BusinessDocumentation/LegalDocs/MidasTechNologiesLLCBylaws.md
Normal file
@@ -0,0 +1,186 @@
|
|||||||
|
The bylaws document for **Midas Technologies Inc.** has been converted into a Markdown file and enhanced for clarity and readability. Here’s the enhanced and fully structured Markdown file:
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Bylaws of Midas Technologies Inc.
|
||||||
|
**Virginia S Corporation**
|
||||||
|
|
||||||
|
## Table of Contents
|
||||||
|
1. [Corporate Offices](#corporate-offices)
|
||||||
|
2. [Shareholders](#shareholders)
|
||||||
|
3. [Board of Directors](#board-of-directors)
|
||||||
|
4. [Officers](#officers)
|
||||||
|
5. [Shares of Stock](#shares-of-stock)
|
||||||
|
6. [Distributions and Dividends](#distributions-and-dividends)
|
||||||
|
7. [Fiscal Year](#fiscal-year)
|
||||||
|
8. [Amendments](#amendments)
|
||||||
|
9. [Indemnification](#indemnification)
|
||||||
|
10. [Miscellaneous Provisions](#miscellaneous-provisions)
|
||||||
|
11. [Adoption of Bylaws](#adoption-of-bylaws)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Corporate Offices
|
||||||
|
|
||||||
|
### Principal Office
|
||||||
|
The corporation’s principal office is located at:
|
||||||
|
**1407 Jennifer Dr, Blacksburg, Virginia**
|
||||||
|
|
||||||
|
### Registered Office
|
||||||
|
The registered office of the corporation is maintained at the same address. Changes to the location may be made at the discretion of the Board of Directors.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Shareholders
|
||||||
|
|
||||||
|
### Annual Meeting
|
||||||
|
- Held on **October 30th at 9:00 pm** at the corporation’s principal office or another location as determined by the Board.
|
||||||
|
- Purpose: **Election of directors** and transaction of other business.
|
||||||
|
|
||||||
|
### Special Meetings
|
||||||
|
- Can be called by the **President, Board of Directors, or shareholders holding at least 30% of shares**.
|
||||||
|
- May be held virtually if necessary.
|
||||||
|
|
||||||
|
### Notice of Meetings
|
||||||
|
Written notice, specifying location, date, and time, will be sent to each shareholder at least **seven days** before the meeting date.
|
||||||
|
|
||||||
|
### Quorum and Voting
|
||||||
|
- A **quorum** requires **50% plus one** of the voting shares.
|
||||||
|
- Decisions require a **majority vote** of the shareholders present, unless otherwise stated by law or these bylaws.
|
||||||
|
|
||||||
|
### Proxies
|
||||||
|
Shareholders may vote by **proxy**, which must be in writing and signed by the shareholder or their authorized representative.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Board of Directors
|
||||||
|
|
||||||
|
### General Powers
|
||||||
|
The Board of Directors is responsible for managing the **business and affairs** of the corporation.
|
||||||
|
|
||||||
|
### Structure and Tenure
|
||||||
|
- **Three directors** on the Board, elected at the annual shareholders’ meeting.
|
||||||
|
- Directors serve until the next annual meeting or until their successors are elected.
|
||||||
|
|
||||||
|
### Meetings
|
||||||
|
- **Regular Meetings**: No notice is required; times and places are determined by the Board.
|
||||||
|
- **Special Meetings**: May be called by the President or directors, with at least **seven days’ notice**.
|
||||||
|
|
||||||
|
### Quorum and Decision-Making
|
||||||
|
A **majority of directors** is required for a quorum, and a majority vote is needed for decisions unless otherwise specified.
|
||||||
|
|
||||||
|
### Compensation
|
||||||
|
Directors may receive **reasonable compensation** for their services, aligned with market rates.
|
||||||
|
|
||||||
|
### Shareholder Agreement
|
||||||
|
**Substantial changes**, such as a sale of the company, require **unanimous consent** from both the Board and shareholders to protect founders’ interests.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Officers
|
||||||
|
|
||||||
|
### Corporate Officers and Responsibilities
|
||||||
|
1. **Chief Data Officer (CDO)**
|
||||||
|
- Oversees data management, analysis, and research for trading algorithms.
|
||||||
|
- **Duties**:
|
||||||
|
- Lead data collection and interpretation for strategic insights.
|
||||||
|
- Collaborate with the CTO to integrate data streams.
|
||||||
|
- Conduct market trend research and model evaluations.
|
||||||
|
- Ensure data security, compliance, and accuracy.
|
||||||
|
|
||||||
|
2. **Chief Technical Officer (CTO)**
|
||||||
|
- Manages technological infrastructure and software development for trading programs.
|
||||||
|
- **Duties**:
|
||||||
|
- Lead software platform development and maintenance.
|
||||||
|
- Manage technical infrastructure, including API integrations.
|
||||||
|
- Collaborate on data-driven strategy with the CDO.
|
||||||
|
- Implement cybersecurity measures.
|
||||||
|
|
||||||
|
3. **Chief Operations Officer (COO)**
|
||||||
|
- Oversees operations, compliance, and investment strategy.
|
||||||
|
- **Duties**:
|
||||||
|
- Manage administrative, financial, and regulatory aspects.
|
||||||
|
- Ensure regulatory compliance.
|
||||||
|
- Oversee company-wide policies and procedures.
|
||||||
|
- Coordinate with CTO and CDO to align technical and data initiatives.
|
||||||
|
|
||||||
|
### Collaboration
|
||||||
|
The CDO, CTO, and COO collaborate on major initiatives, requiring **consensus** on decisions affecting the company’s direction or strategic assets.
|
||||||
|
|
||||||
|
### Election and Term
|
||||||
|
Officers are elected by the Board at the annual meeting and serve a **one-year term** or until successors are elected.
|
||||||
|
|
||||||
|
### Removal and Vacancies
|
||||||
|
Officers may be removed by a majority vote if deemed necessary, and any vacancies are filled by the Board.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Shares of Stock
|
||||||
|
|
||||||
|
### Issuance of Shares
|
||||||
|
The Board has the authority to **issue shares** and set terms for stock issuance.
|
||||||
|
|
||||||
|
### Stock Certificates
|
||||||
|
Shares can be represented by **certificates or electronically**. Certificates display the corporation’s name, shareholder’s name, and number of shares.
|
||||||
|
|
||||||
|
### Transfer of Shares
|
||||||
|
Shareholders can transfer shares on the corporation’s books with proper authorization.
|
||||||
|
|
||||||
|
### Restrictions on Transfer
|
||||||
|
To maintain S Corporation status, any share transfer must first be offered to the corporation or other shareholders before outside parties.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Distributions and Dividends
|
||||||
|
|
||||||
|
### Distributions
|
||||||
|
The Board of Directors determines shareholder distributions, following state and federal regulations.
|
||||||
|
|
||||||
|
### Dividends
|
||||||
|
Dividends may be declared at the Board’s discretion, adhering to S Corporation rules and the corporation’s financial status.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Fiscal Year
|
||||||
|
|
||||||
|
The corporation’s fiscal year aligns with the **calendar year**, subject to change by the Board of Directors.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Amendments
|
||||||
|
|
||||||
|
The bylaws can be **amended or repealed** by either the Board of Directors or shareholders during regular or special meetings. Amendments require a **majority vote**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Indemnification
|
||||||
|
|
||||||
|
Directors, officers, and agents of the corporation are indemnified against liabilities incurred in performing their duties, as permitted by **Virginia law**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Miscellaneous Provisions
|
||||||
|
|
||||||
|
1. **Corporate Records**: Records of corporate activities are maintained at the principal office.
|
||||||
|
2. **Corporate Seal**: A corporate seal may be adopted, though not required for document validity.
|
||||||
|
3. **Right of Inspection**: Shareholders have the right to inspect records with prior written request.
|
||||||
|
4. **Intellectual Property**: Proprietary algorithms, data models, and software developed for the corporation belong to the corporation.
|
||||||
|
5. **Conflict Resolution**: The corporation seeks mediation or arbitration before litigation in case of internal disputes.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Adoption of Bylaws
|
||||||
|
|
||||||
|
These bylaws were adopted by the Board of Directors of **Midas Technologies Inc.** on **November 11, 2024**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Signatures:**
|
||||||
|
|
||||||
|
Chief Operations Officer
|
||||||
|
Chief Technical Officer
|
||||||
|
Chief Data Officer
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
This enhanced version provides clear formatting and structure for readability and accessibility. Let me know if you need further adjustments or additional files processed!
|
||||||
245
PoliciesAndStandards/CodingStandards.md
Normal file
245
PoliciesAndStandards/CodingStandards.md
Normal file
@@ -0,0 +1,245 @@
|
|||||||
|
# MiadTechnologies Coding Standards
|
||||||
|
|
||||||
|
This document details the coding standards and practices for maintaining consistency, readability, and quality in the codebase for all contributors. These guidelines apply across programming languages and environments used within the project, focusing primarily on Python and any related languages used for interoperability.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Table of Contents
|
||||||
|
1. [Python Coding Standards](#python-coding-standards)
|
||||||
|
2. [Virtual Environments and Dependency Management](#virtual-environments-and-dependency-management)
|
||||||
|
3. [Interfacing with Other Languages](#interfacing-with-other-languages)
|
||||||
|
4. [Documentation Standards for Code](#documentation-standards-for-code)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Python Coding Standards
|
||||||
|
|
||||||
|
Our primary codebase is in Python, and we adhere strictly to **PEP8** guidelines with additional standards to ensure clarity and consistency.
|
||||||
|
|
||||||
|
### PEP8 Guidelines and Best Practices
|
||||||
|
- **Naming Conventions**:
|
||||||
|
- **Variables and functions**: Use `snake_case` for readability.
|
||||||
|
- **Classes**: Use `PascalCase`.
|
||||||
|
- **Constants**: Use `ALL_CAPS`.
|
||||||
|
- **Line Length**: Limit lines to **79 characters** for readability.
|
||||||
|
- **Indentation**: Use **4 spaces per indentation level**.
|
||||||
|
- **Docstrings**: Follow [PEP 257](https://www.python.org/dev/peps/pep-0257/) conventions.
|
||||||
|
- Use docstrings for all public modules, classes, and functions.
|
||||||
|
- Structure them using the [Google docstring style](https://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_google.html).
|
||||||
|
- **Comments**: Add comments as needed to clarify code functionality, especially around complex logic. Avoid redundant comments.
|
||||||
|
|
||||||
|
### Jupyter Notebook Usage
|
||||||
|
While Jupyter notebooks are valuable for experimentation, they should not be submitted directly to the repository unless absolutely necessary. Instead:
|
||||||
|
1. **Convert the notebook to a `.py` file** before adding it to the repo.
|
||||||
|
- In Jupyter, navigate to `File > Download as > Python (.py)` to obtain a `.py` version of the notebook.
|
||||||
|
2. **Document the Python file** properly and integrate it with the existing codebase standards.
|
||||||
|
|
||||||
|
### Python Best Practices Quick Reference
|
||||||
|
|
||||||
|
Follow these essential Python best practices to ensure code consistency across the project:
|
||||||
|
|
||||||
|
- **Use List Comprehensions**: Prefer list comprehensions over traditional loops for concise code.
|
||||||
|
```python
|
||||||
|
# Recommended
|
||||||
|
squares = [x**2 for x in range(10)]
|
||||||
|
```
|
||||||
|
* Avoid Global Variables: Limit the use of global variables, especially in modules intended for import.
|
||||||
|
|
||||||
|
* String Formatting: Use f-strings (formatted string literals) for improved readability in Python 3.6 and above.
|
||||||
|
|
||||||
|
```python
|
||||||
|
name = "Alice"
|
||||||
|
print(f"Hello, {name}!")
|
||||||
|
```
|
||||||
|
|
||||||
|
* Error Handling: Use specific exceptions where possible. Avoid catching all exceptions with except Exception.
|
||||||
|
|
||||||
|
* PEP8 Line Length: Adhere to a line length of 79 characters, and use 4 spaces per indentation level.
|
||||||
|
|
||||||
|
* Docstrings: Use Google-style docstrings to document functions, modules, and classes.
|
||||||
|
|
||||||
|
>Refer to PEP8 and Google Python Style Guide for detailed information on Python coding standards.
|
||||||
|
|
||||||
|
### Recommended Tools
|
||||||
|
- **Flake8**: Enforces PEP8 standards.
|
||||||
|
- **Black**: Automatic formatter for consistent styling.
|
||||||
|
- **isort**: Automatically organizes imports.
|
||||||
|
|
||||||
|
These tools can be added to your development environment for smoother compliance with coding standards.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Virtual Environments and Dependency Management
|
||||||
|
|
||||||
|
Using a virtual environment isolates dependencies and keeps the project environment consistent.
|
||||||
|
|
||||||
|
### Setting Up a Virtual Environment
|
||||||
|
1. **Create the virtual environment** in the project root:
|
||||||
|
```bash
|
||||||
|
python -m venv venv
|
||||||
|
```
|
||||||
|
2. **Activate the environment**:
|
||||||
|
- On macOS/Linux:
|
||||||
|
```bash
|
||||||
|
source venv/bin/activate
|
||||||
|
```
|
||||||
|
- On Windows:
|
||||||
|
```bash
|
||||||
|
.\venv\Scripts\activate
|
||||||
|
```
|
||||||
|
3. **Install dependencies** from `requirements.txt`:
|
||||||
|
```bash
|
||||||
|
pip install -r requirements.txt
|
||||||
|
```
|
||||||
|
|
||||||
|
### Managing Dependencies with `requirements.txt`
|
||||||
|
All project dependencies should be added to `requirements.txt`. When new packages are added:
|
||||||
|
1. Install the package using `pip`.
|
||||||
|
2. Update `requirements.txt` by freezing the environment:
|
||||||
|
```bash
|
||||||
|
pip freeze > requirements.txt
|
||||||
|
```
|
||||||
|
|
||||||
|
### Important Note
|
||||||
|
- **Do not push the `venv` directory** to the repository. The virtual environment is a local development tool and should remain excluded in `.gitignore`.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
Here's a more detailed and enhanced section for the **Interfacing with Other Languages** area, incorporating standards and industry best practices across each language, file format, and tool.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Interfacing with Other Languages
|
||||||
|
|
||||||
|
Python’s flexibility allows it to integrate with other languages, databases, and formats, which is particularly beneficial for high-performance tasks, front-end functionality, data exchange, and efficient file handling. Below are the industry standards, best practices, and interfacing guidelines for each language or format commonly used with Python.
|
||||||
|
|
||||||
|
### 1. C (CPython and C Extensions)
|
||||||
|
C is often used in Python projects for performance-critical modules and low-level operations.
|
||||||
|
- **Coding Standards**: Follow the [GNU Coding Standards](https://www.gnu.org/prep/standards/).
|
||||||
|
- Use `snake_case` for variable and function names.
|
||||||
|
- Avoid global variables, and encapsulate functions within modules.
|
||||||
|
- **Documentation**: Use comments within `.c` and `.h` files, explaining complex logic and including a description of each function.
|
||||||
|
- Follow structured comment headers for each function, detailing parameters, expected return values, and purpose.
|
||||||
|
- **Interfacing with Python**:
|
||||||
|
- Use `ctypes` or `cffi` for interfacing.
|
||||||
|
- **Example**: Use `ctypes` to call a C function from Python:
|
||||||
|
```c
|
||||||
|
// function.c
|
||||||
|
int add(int a, int b) {
|
||||||
|
return a + b;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
- Use `setup.py` with `distutils` to compile C extensions for easy distribution.
|
||||||
|
|
||||||
|
### 2. TypeScript and JavaScript
|
||||||
|
TypeScript, a typed superset of JavaScript, should be used for type safety and maintainability on the front-end.
|
||||||
|
- **Coding Standards**: Follow the [Airbnb JavaScript Style Guide](https://github.com/airbnb/javascript).
|
||||||
|
- Use `camelCase` for variables and function names.
|
||||||
|
- Prefer `const` and `let` over `var`.
|
||||||
|
- **Documentation**: Comment functions and classes with JSDoc.
|
||||||
|
- Use TypeScript's type annotations to document data types explicitly.
|
||||||
|
- **Interfacing**:
|
||||||
|
- Use `pyodide` or REST APIs to communicate between Python and JavaScript.
|
||||||
|
- When possible, separate concerns by keeping Python back-end tasks independent of TypeScript front-end logic, communicating only through defined APIs.
|
||||||
|
|
||||||
|
### 3. Go
|
||||||
|
Go is efficient for concurrent tasks, and is often used alongside Python for backend services or tasks needing efficient multithreading.
|
||||||
|
- **Coding Standards**: Follow [Effective Go](https://golang.org/doc/effective_go.html).
|
||||||
|
- Use `PascalCase` for exported (public) identifiers and `camelCase` for private ones.
|
||||||
|
- Format code with `go fmt` to maintain consistency.
|
||||||
|
- **Documentation**:
|
||||||
|
- Add a comment above each function explaining its functionality, parameters, and expected return values.
|
||||||
|
- **Interfacing**:
|
||||||
|
- Use `cgo` to call C functions from Go if needed, or implement a REST API to interact with Python.
|
||||||
|
|
||||||
|
### 4. Rust
|
||||||
|
Rust is a high-performance language with strong memory safety guarantees, making it suitable for secure, efficient modules in Python.
|
||||||
|
- **Standards**: Follow the [Rust API Guidelines](https://rust-lang.github.io/api-guidelines/).
|
||||||
|
- Use `snake_case` for function and variable names, and `CamelCase` for structs and enums.
|
||||||
|
- Use `clippy` for linting and `rustfmt` for consistent formatting.
|
||||||
|
- **Documentation**:
|
||||||
|
- Use triple slashes (`///`) for documentation comments on functions and modules.
|
||||||
|
- Each public function should explain parameters, return values, and potential errors.
|
||||||
|
- **Interfacing**:
|
||||||
|
- Use `pyo3` for embedding Rust code in Python or `maturin` for building and publishing Python packages containing Rust code.
|
||||||
|
|
||||||
|
### 5. JSON
|
||||||
|
JSON is a lightweight data-interchange format and is frequently used in Python projects for configuration and data exchange.
|
||||||
|
- **Format**: Follow strict schema validation to ensure data consistency.
|
||||||
|
- Use lowercase keys in `snake_case`.
|
||||||
|
- Avoid deeply nested structures; keep depth manageable for readability.
|
||||||
|
- **Best Practices**:
|
||||||
|
- Validate JSON against a schema using tools like `jsonschema`.
|
||||||
|
- Use consistent encoding (UTF-8) and 4-space indentation.
|
||||||
|
|
||||||
|
### 6. CSV
|
||||||
|
CSV files are widely used for tabular data storage and exchange.
|
||||||
|
- **Format**: Always include headers as the first row, and use commas (`,`) as delimiters.
|
||||||
|
- **Best Practices**:
|
||||||
|
- Handle missing data by filling with placeholders or removing empty rows if appropriate.
|
||||||
|
- Use Python’s `csv` library, and include headers in the file for clarity.
|
||||||
|
- Ensure data types are consistent across columns (e.g., dates, numbers).
|
||||||
|
|
||||||
|
### 7. SQL (Database Standards)
|
||||||
|
SQL databases are essential for structured data storage and querying.
|
||||||
|
- **Naming Conventions**:
|
||||||
|
- Use `snake_case` for table and column names.
|
||||||
|
- Avoid special characters and reserved keywords in table or column names.
|
||||||
|
- **Standards**: Follow [SQL Style Guide](https://www.sqlstyle.guide/).
|
||||||
|
- Use constraints and foreign keys for data integrity.
|
||||||
|
- Normalize data as needed, but consider denormalization for performance in specific cases.
|
||||||
|
- **Indexing**: Index frequently queried columns for faster retrieval.
|
||||||
|
- **Transactions**: Wrap changes in transactions to ensure data consistency, and roll back on errors.
|
||||||
|
|
||||||
|
### 8. Docker
|
||||||
|
Docker standardizes development environments and deployment by containerizing applications.
|
||||||
|
- **Dockerfile Standards**:
|
||||||
|
- Use multi-stage builds to optimize image size.
|
||||||
|
- Only include production dependencies in the final image.
|
||||||
|
- Use environment variables for configuration rather than hardcoding values.
|
||||||
|
- **Directory Structure**:
|
||||||
|
- Place Docker-related files in a `docker/` directory.
|
||||||
|
- Use `docker-compose.yml` for multi-container setups.
|
||||||
|
- **Best Practices**:
|
||||||
|
- Use `.dockerignore` to exclude unnecessary files, like logs and local configuration.
|
||||||
|
- Always use stable tags for dependencies instead of `latest`.
|
||||||
|
|
||||||
|
### 9. Binary Building for Python
|
||||||
|
For performance-critical Python code, consider building binaries.
|
||||||
|
- **Tools**:
|
||||||
|
- Use `Cython` to compile Python code into C, then build as a binary.
|
||||||
|
- Alternatively, use `PyInstaller` to package Python scripts as standalone executables.
|
||||||
|
- **Best Practices**:
|
||||||
|
- Ensure binaries are compatible with target deployment environments.
|
||||||
|
- Document the binary build process for reproducibility.
|
||||||
|
|
||||||
|
### 10. Makefiles
|
||||||
|
**Makefiles** provide a standardized way to compile and manage dependencies, particularly for non-Python code.
|
||||||
|
- **Structure**:
|
||||||
|
- Place the `Makefile` in the root of the project.
|
||||||
|
- Organize commands for easy readability, grouping related commands together.
|
||||||
|
- **Common Targets**:
|
||||||
|
- `build`: Compile code, if needed.
|
||||||
|
- `clean`: Remove compiled files and dependencies.
|
||||||
|
- `test`: Run test suites.
|
||||||
|
- `install`: Set up dependencies or environment configurations.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Documentation Standards for Code
|
||||||
|
|
||||||
|
Clear and concise documentation is essential for long-term project maintainability.
|
||||||
|
|
||||||
|
### Docstring and In-Code Documentation
|
||||||
|
- **Functions and Classes**: Use [Google Style Docstrings](https://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_google.html).
|
||||||
|
- Each docstring should describe what the function does, input parameters, return values, and any exceptions raised.
|
||||||
|
- **In-Line Comments**: Only add comments where needed to explain non-obvious parts of the code.
|
||||||
|
- **Module-Level Documentation**: Provide a brief overview at the top of each file explaining its purpose and any key dependencies.
|
||||||
|
|
||||||
|
### README.md for Each Module
|
||||||
|
Each root module should contain a `README.md` file covering:
|
||||||
|
- **Overview**: High-level description of the module’s functionality.
|
||||||
|
- **Setup**: Dependencies, pip installs, libraries, and setup instructions.
|
||||||
|
- **Usage**: Sample commands or code for running the module.
|
||||||
|
- **API Documentation**: If applicable, list available functions, classes, or endpoints.
|
||||||
|
|
||||||
125
PoliciesAndStandards/CommunicationStandards.md
Normal file
125
PoliciesAndStandards/CommunicationStandards.md
Normal file
@@ -0,0 +1,125 @@
|
|||||||
|
# Collaboration and Communication
|
||||||
|
|
||||||
|
## Table of Contents
|
||||||
|
1. [Purpose](#purpose)
|
||||||
|
2. [Communication Channels](#communication-channels)
|
||||||
|
- [GitHub Issues](#github-issues)
|
||||||
|
- [Pull Requests (PRs)](#pull-requests-prs)
|
||||||
|
- [Team Meetings](#team-meetings)
|
||||||
|
- [Direct Messaging (DMs)](#direct-messaging-dms)
|
||||||
|
3. [Collaborative Coding Practices](#collaborative-coding-practices)
|
||||||
|
4. [Documentation Requirements](#documentation-requirements)
|
||||||
|
5. [Conflict Resolution](#conflict-resolution)
|
||||||
|
6. [File-Path Standards and Naming Conventions](#file-path-standards-and-naming-conventions)
|
||||||
|
7. [Labor Distribution and Task Assignment](#labor-distribution-and-task-assignment)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
This document outlines collaboration and communication guidelines for our team, ensuring alignment, productivity, and clarity as we work on projects. Effective use of these practices will help streamline progress and minimize misunderstandings.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Communication Channels
|
||||||
|
|
||||||
|
1. **GitHub Issues**
|
||||||
|
- **Purpose**: Use GitHub Issues for bug tracking, feature requests, and all development-related discussions.
|
||||||
|
- **Best Practices**:
|
||||||
|
- Assign labels (e.g., `bug`, `enhancement`, `documentation`) to categorize each issue.
|
||||||
|
- Assign issues to relevant team members and add milestones where applicable.
|
||||||
|
- Keep all discussions regarding the issue within its thread to retain context.
|
||||||
|
|
||||||
|
2. **Pull Requests (PRs)**
|
||||||
|
- **Purpose**: PRs facilitate code reviews and collaborative discussions on changes before merging.
|
||||||
|
- **Best Practices**:
|
||||||
|
- Link each PR to the corresponding issue.
|
||||||
|
- Use the provided **PR Template** to give detailed context and link to relevant resources.
|
||||||
|
- Use **GitHub Reviews** to comment on specific code sections or suggest improvements.
|
||||||
|
- Ensure all discussions are resolved before finalizing the merge.
|
||||||
|
|
||||||
|
3. **Team Meetings**
|
||||||
|
- **Purpose**: Conduct periodic meetings to discuss project updates, roadblocks, and future priorities.
|
||||||
|
- **Frequency**: Weekly, or as needed based on project milestones.
|
||||||
|
- **Agenda**: Each member should come prepared with updates, questions, and any roadblocks requiring group input.
|
||||||
|
|
||||||
|
4. **Direct Messaging (DMs)**
|
||||||
|
- **Purpose**: Use text messaging for quick, urgent issues.
|
||||||
|
- **Future Option**: A company Discord or similar platform may be established for more structured and real-time communication, enabling different channels for topics like bugs, general updates, and discussions.
|
||||||
|
- **Note**: Text messaging or direct messages are meant for time-sensitive issues and should not replace documented discussions crucial to the project.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Collaborative Coding Practices
|
||||||
|
|
||||||
|
1. **Code Reviews**
|
||||||
|
- Open a PR for any code that is ready for review.
|
||||||
|
- Assign relevant team members as reviewers, tagging specific people for feedback on particular areas.
|
||||||
|
- Provide constructive feedback with explanations to clarify your suggestions.
|
||||||
|
|
||||||
|
2. **Issue Assignment and Management**
|
||||||
|
- Assign each issue to one or more contributors.
|
||||||
|
- Regularly update the issue status by changing labels or closing it when complete.
|
||||||
|
- For large tasks, break down the issue into smaller, manageable sub-tasks and assign them accordingly.
|
||||||
|
|
||||||
|
3. **Pair Programming and Knowledge Sharing**
|
||||||
|
- For complex features or debugging, consider pair programming with another team member.
|
||||||
|
- Document insights gained from these sessions, especially any solutions for particularly challenging issues or bugs.
|
||||||
|
|
||||||
|
### Task Ownership and Assignment Changes
|
||||||
|
|
||||||
|
To ensure transparency and accountability within the team, follow these guidelines for task ownership:
|
||||||
|
|
||||||
|
- **Task Ownership**: Each issue should have a clearly assigned owner responsible for its completion. If you are assigned a task, regularly update the issue with your progress.
|
||||||
|
- **Reassignment Protocol**: If you are unable to complete a task or require assistance, reassign it to a relevant team member or reach out to the project maintainer.
|
||||||
|
- **Ownership Transfer**: When transferring ownership, add a comment to the GitHub issue explaining the reason and notify the new owner directly. Ensure the transition is smooth to maintain workflow continuity.
|
||||||
|
|
||||||
|
Maintaining clear task ownership helps keep the project organized and reduces overlap or duplicated effort.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Documentation Requirements
|
||||||
|
|
||||||
|
- Each project module should contain a `README.md` with setup instructions, usage examples, and module-specific details.
|
||||||
|
- Follow **Documentation Standards.md** for consistency in all documentation.
|
||||||
|
- Comment complex or non-obvious code to enhance clarity for all team members.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Conflict Resolution
|
||||||
|
|
||||||
|
1. **Technical Disagreements**
|
||||||
|
- Address technical disagreements within the PR or issue thread.
|
||||||
|
- If unresolved, escalate to a team meeting where a consensus can be reached.
|
||||||
|
|
||||||
|
2. **Responsibilities and Expectations**
|
||||||
|
- Document each team member’s responsibilities and ensure clarity on roles to prevent misunderstandings.
|
||||||
|
- If conflicts arise regarding tasks, discuss openly in team meetings or escalate to the project maintainer.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## File-Path Standards and Naming Conventions
|
||||||
|
|
||||||
|
- Adhere to the **File-Path Standards** for directory structures and file naming conventions.
|
||||||
|
- Following consistent naming conventions helps streamline navigation and allows the team to understand the project structure quickly.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Labor Distribution and Task Assignment
|
||||||
|
|
||||||
|
**GitHub Project Boards and Issues** provide a structured method for distributing tasks across the team:
|
||||||
|
1. **Create Project Boards**
|
||||||
|
- **Purpose**: Use GitHub Project Boards to organize issues into columns such as `To Do`, `In Progress`, and `Completed`.
|
||||||
|
- **Best Practices**:
|
||||||
|
- Ensure each task or issue is visible on the board.
|
||||||
|
- Regularly update the status of each issue by moving it to the relevant column as work progresses.
|
||||||
|
|
||||||
|
2. **Assigning Issues and Tasks**
|
||||||
|
- For each feature or task, create an issue in GitHub and assign it to the responsible contributor.
|
||||||
|
- Use tags like `priority`, `in-progress`, and `review-needed` for clarity on the status and urgency of each task.
|
||||||
|
|
||||||
|
3. **Milestones**
|
||||||
|
- Define **milestones** for specific project phases (e.g., `v1.0 Launch`, `Feature Complete`).
|
||||||
|
- Assign issues to milestones to maintain a timeline and prioritize critical tasks.
|
||||||
|
- Each milestone should have an estimated completion date and a list of issues to be resolved before the milestone is considered complete.
|
||||||
|
|
||||||
170
PoliciesAndStandards/DocumentationStandards.md
Normal file
170
PoliciesAndStandards/DocumentationStandards.md
Normal file
@@ -0,0 +1,170 @@
|
|||||||
|
# Documentation Standards
|
||||||
|
|
||||||
|
## Table of Contents
|
||||||
|
1. [Overview](#overview)
|
||||||
|
2. [Global Documentation Structure](#global-documentation-structure)
|
||||||
|
3. [Module-Specific Documentation](#module-specific-documentation)
|
||||||
|
4. [Documentation Format and Naming Conventions](#documentation-format-and-naming-conventions)
|
||||||
|
5. [File Requirements for Python Modules](#file-requirements-for-python-modules)
|
||||||
|
6. [Code Documentation Practices](#code-documentation-practices)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
This document defines the standards for documenting business, technical, and code-related affairs within the repository. It ensures that all contributors understand how and where to document essential aspects of the project, including code structure, usage, and business elements.
|
||||||
|
|
||||||
|
**Footnote:** While the overarching program is under active development, documentation must be updated with each pull request or addition to maintain consistency and clarity as the project grows.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Global Documentation Structure
|
||||||
|
|
||||||
|
All global documentation is stored under the `/docs` directory and is organized into the following key areas:
|
||||||
|
|
||||||
|
1. **Business Documentation**:
|
||||||
|
- Contains non-technical documents that relate to company operations, legal compliance, project plans, business strategies, and any necessary licenses or contracts.
|
||||||
|
- **Directory**: `/docs/business`
|
||||||
|
- **Examples**: Business plans, contracts, project outlines, licenses.
|
||||||
|
|
||||||
|
2. **Policies and Standards**:
|
||||||
|
- Contains files outlining the coding, review, and workflow standards.
|
||||||
|
- **Directory**: `/docs/policies-and-standards`
|
||||||
|
- **Examples**: `GitAndGitHubStandards.md`, `BranchNamingConventions.md`, `CodingStandards.md`.
|
||||||
|
|
||||||
|
3. **Man Pages**:
|
||||||
|
- Stores all program-related documentation for the entire codebase.
|
||||||
|
- **Directory**: `/docs/manpages`
|
||||||
|
- **Examples**: README files detailing how to use, deploy, and modify the overarching program.
|
||||||
|
|
||||||
|
Each sub-directory should contain a README.md that outlines its purpose and lists the contents within.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Module-Specific Documentation
|
||||||
|
|
||||||
|
All **root modules** within the overarching program should contain their own `README.md` files. These files should act as module-specific documentation, providing:
|
||||||
|
|
||||||
|
1. **Overview**:
|
||||||
|
- A brief explanation of the module’s functionality and its purpose in the larger program.
|
||||||
|
|
||||||
|
2. **Installation and Setup**:
|
||||||
|
- Instructions for setting up the module, including any dependencies not covered in the global requirements file.
|
||||||
|
|
||||||
|
3. **Usage**:
|
||||||
|
- How to run and utilize the module, including examples of inputs, expected outputs, and special configurations.
|
||||||
|
|
||||||
|
4. **Development Guidelines**:
|
||||||
|
- If applicable, detail any specific guidelines for contributing to the module, such as coding standards, testing guidelines, or branch usage specific to the module.
|
||||||
|
|
||||||
|
5. **Version and Dependencies**:
|
||||||
|
- Each module should have its own `requirements.txt` file that lists the dependencies required for it to function. This file will be merged into the main program’s `requirements.txt` by the admins.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Documentation Format and Naming Conventions
|
||||||
|
|
||||||
|
### Format
|
||||||
|
|
||||||
|
- **Markdown** (`.md`) or **Plain Text** (`.txt`) formats are acceptable for all documentation.
|
||||||
|
- The language should be formal yet accessible, avoiding technical jargon where possible to ensure clarity for all team members and future collaborators.
|
||||||
|
|
||||||
|
### Naming Conventions
|
||||||
|
|
||||||
|
- **Documentation files** must be in **Capitalized Case** with no spaces, using only letters and alphanumeric characters.
|
||||||
|
- **Examples**: `DocumentationStandards.md`, `GitAndGitHubStandards.md`
|
||||||
|
- **Code files** should follow **lowercase with underscores** for Python, with no spaces or special characters.
|
||||||
|
- **Examples**: `data_processing.py`, `config_handler.py`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## File Requirements for Python Modules
|
||||||
|
|
||||||
|
### Main `requirements.txt`
|
||||||
|
|
||||||
|
A main `requirements.txt` file will exist in the root directory of the program. This file aggregates all module-specific dependencies to provide a comprehensive list of requirements for the entire program.
|
||||||
|
|
||||||
|
### Module-Specific `requirements.txt`
|
||||||
|
|
||||||
|
- Each root module in Python must include its own `requirements.txt` file, specifying only the dependencies necessary for that module.
|
||||||
|
- Upon review, the admins will incorporate module-specific requirements into the main `requirements.txt`.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Code Documentation Practices
|
||||||
|
|
||||||
|
### General Code Documentation Guidelines
|
||||||
|
|
||||||
|
Documentation within code should provide clarity and context without redundancy. Focus on documenting the **why** and **how** rather than the **what**.
|
||||||
|
|
||||||
|
- **Functions and Methods**:
|
||||||
|
- Include docstrings for all public functions and methods. These should follow the [Google Docstring Style](https://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_google.html) for consistency and readability.
|
||||||
|
|
||||||
|
- **Classes**:
|
||||||
|
- Each class should have a docstring explaining its purpose and any unique attributes or methods. This docstring should summarize the role of the class in the module.
|
||||||
|
|
||||||
|
### Specific Documentation Guidelines
|
||||||
|
|
||||||
|
1. **Function-Level Documentation**:
|
||||||
|
- Include a brief docstring at the beginning of each function that explains:
|
||||||
|
- **Parameters**: List and explain the function’s input parameters.
|
||||||
|
- **Returns**: Describe the data returned by the function.
|
||||||
|
- **Raises**: Detail any exceptions that the function might raise.
|
||||||
|
- **Example**:
|
||||||
|
```python
|
||||||
|
def process_data(data: list) -> dict:
|
||||||
|
"""
|
||||||
|
Processes input data and returns a dictionary of results.
|
||||||
|
|
||||||
|
Args:
|
||||||
|
data (list): List of data points to be processed.
|
||||||
|
|
||||||
|
Returns:
|
||||||
|
dict: Processed results including mean and standard deviation.
|
||||||
|
|
||||||
|
Raises:
|
||||||
|
ValueError: If data is not a list of numbers.
|
||||||
|
"""
|
||||||
|
```
|
||||||
|
|
||||||
|
2. **Class-Level Documentation**:
|
||||||
|
- Use class-level docstrings to summarize the purpose and usage of the class.
|
||||||
|
- **Example**:
|
||||||
|
```python
|
||||||
|
class DataProcessor:
|
||||||
|
"""
|
||||||
|
Class for processing and analyzing data.
|
||||||
|
|
||||||
|
This class provides methods for statistical analysis and
|
||||||
|
data transformation. Suitable for numerical data inputs.
|
||||||
|
|
||||||
|
Attributes:
|
||||||
|
data (list): List of numerical data.
|
||||||
|
"""
|
||||||
|
```
|
||||||
|
|
||||||
|
3. **In-Line Comments**:
|
||||||
|
- Use in-line comments sparingly and only to clarify complex logic or non-standard decisions in the code.
|
||||||
|
- Avoid obvious comments; instead, focus on why something is done rather than what is being done.
|
||||||
|
|
||||||
|
### API Documentation Standards
|
||||||
|
|
||||||
|
For code that interfaces with external services or shared modules, follow these standards for documenting APIs:
|
||||||
|
|
||||||
|
- **Endpoints**: Clearly list each endpoint and its purpose in the API documentation.
|
||||||
|
- **Parameters**: Define all required and optional parameters, including data types and default values.
|
||||||
|
- **Response Format**: Describe the structure and data types returned by each endpoint.
|
||||||
|
- **Error Handling**: Document possible error codes or messages and recommended solutions for common issues.
|
||||||
|
- **Usage Examples**: Provide examples showing both requests and responses to illustrate expected usage.
|
||||||
|
|
||||||
|
API documentation should be added to the `docs/ManPages/api` directory. Where possible, maintain consistency with other project documentation.
|
||||||
|
|
||||||
|
### Documentation Updates with Pull Requests
|
||||||
|
|
||||||
|
Whenever a pull request (PR) introduces new features, refactors existing code, or modifies functionality, relevant documentation files must be updated accordingly. Contributors are responsible for ensuring that:
|
||||||
|
|
||||||
|
- All impacted `README.md` files, both module-specific and global, reflect the latest changes.
|
||||||
|
- Necessary updates to docstrings, function comments, and inline comments are made to maintain clarity and usability.
|
||||||
|
|
||||||
|
*Footnote: This process is currently noted for future enforcement once the overarching program is complete.*
|
||||||
|
|
||||||
176
PoliciesAndStandards/FilePathStandards.md
Normal file
176
PoliciesAndStandards/FilePathStandards.md
Normal file
@@ -0,0 +1,176 @@
|
|||||||
|
# File Path Standards
|
||||||
|
|
||||||
|
## Table of Contents
|
||||||
|
1. [Purpose](#purpose)
|
||||||
|
2. [General Directory Structure](#general-directory-structure)
|
||||||
|
3. [Naming Conventions](#naming-conventions)
|
||||||
|
4. [Special Conventions](#special-conventions)
|
||||||
|
5. [Example Directory Structure](#example-directory-structure)
|
||||||
|
6. [Guidelines for Adding New Files](#guidelines-for-adding-new-files)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
This document establishes the standards for organizing, naming, and structuring files and directories across all projects within **MidasTechnologies**. Following these guidelines ensures a clean, predictable file layout, making it easy for team members to navigate, understand, and maintain the repository. Clear structure contributes to project scalability, maintainability, and a smoother development experience.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## General Directory Structure
|
||||||
|
|
||||||
|
The project root directory, **MidasTechnologies**, includes key folders for code, tests, configuration, documentation, and other resources. The layout below provides an organized structure for optimal project navigation and resource management.
|
||||||
|
|
||||||
|
```
|
||||||
|
MidasTechnologies/
|
||||||
|
│
|
||||||
|
├── src/ # Source code for the entire project
|
||||||
|
│ ├── neural-network/ # Neural network-related code
|
||||||
|
│ ├── data-collection/ # Code and data processing tools for data collection
|
||||||
|
│ │ ├── tests/ # Contains unit tests, integration tests, and test resources
|
||||||
|
│ │ └── ... # Additional data collection code modules
|
||||||
|
│ ├── sentiment-analysis/ # Sentiment analysis-related code
|
||||||
|
│ ├── frontend/ # Frontend-related code and assets
|
||||||
|
│ └── ... # Additional modules or features as needed
|
||||||
|
│
|
||||||
|
├── docs/ # All project documentation
|
||||||
|
│ ├── BusinessDocumentation/ # Business-related documentation
|
||||||
|
│ ├── ManPages/ # Global code documentation
|
||||||
|
│ └── PoliciesAndStandards/ # Documentation standards, policies, and guidelines
|
||||||
|
│
|
||||||
|
├── config/ # Configuration files and environment settings
|
||||||
|
├── data/ # Static data files for the entire project
|
||||||
|
├── scripts/ # Utility and setup scripts (e.g., deployment scripts)
|
||||||
|
├── examples/ # Examples and sample code for demonstrating project usage
|
||||||
|
└── assets/ # Static assets (images, icons, etc.) for frontend or docs
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Naming Conventions
|
||||||
|
|
||||||
|
1. **File Names**
|
||||||
|
- All file names should be in **lowercase** and use **underscores** to replace spaces (e.g., `data_loader.py`).
|
||||||
|
- Avoid any whitespace, special characters, or symbols. Stick to letters, numbers, and underscores.
|
||||||
|
- If a file is specific to a particular module or feature, use a descriptive prefix or suffix to clarify its purpose, such as `user_model.py`.
|
||||||
|
|
||||||
|
2. **Directory Names**
|
||||||
|
- Directory names should be in **all lowercase** and use hyphens (`-`) to replace spaces (e.g., `user-auth`).
|
||||||
|
- Avoid whitespace and special characters to maintain consistency.
|
||||||
|
- **src/ Directories**: Organize files by functionality, such as `api`, `models`, `services`, `data-collection`, and `utils`.
|
||||||
|
|
||||||
|
3. **Document Files**
|
||||||
|
- **Documentation** should be in **Markdown (.md)** or **Plain Text (.txt)** format.
|
||||||
|
- Documentation filenames should follow a capitalized naming convention (e.g., `README.md` or `GitAndGithubStandards.md`).
|
||||||
|
|
||||||
|
4. **Environment Variables**
|
||||||
|
- Use **all uppercase** with underscores (e.g., `DATABASE_URL`).
|
||||||
|
|
||||||
|
5. **Configuration Files**
|
||||||
|
- Use `.yaml` or `.json` for configuration files to maintain readability and consistency.
|
||||||
|
|
||||||
|
6. **Classes**
|
||||||
|
- Class names should follow **PascalCase** (e.g., `UserService`).
|
||||||
|
|
||||||
|
### GitHub File Naming and Directory Limitations
|
||||||
|
|
||||||
|
When creating or modifying file names and directories, keep in mind GitHub's limitations and best practices:
|
||||||
|
|
||||||
|
- **Character Limit**: File and directory names should not exceed 255 characters.
|
||||||
|
- **Special Characters**: Avoid using special characters (e.g., `@`, `!`, `$`, `%`) as they may cause compatibility issues across different operating systems.
|
||||||
|
- **Case Sensitivity**: GitHub is case-sensitive, so `FilePathStandards.md` and `filepathstandards.md` are treated as distinct files. Use consistent lowercase naming for all files as per our standards.
|
||||||
|
- **Path Depth**: Aim to keep directory nesting shallow to improve readability and reduce navigation complexity.
|
||||||
|
|
||||||
|
Adhering to these guidelines will ensure compatibility across different development environments and maintain uniformity within the repository.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Special Conventions
|
||||||
|
|
||||||
|
1. **Documentation Directories**
|
||||||
|
- Documentation directories in `docs/` are an exception to general naming conventions. Documentation files use **Capitalized Names** (e.g., `ManPages`, `BusinessDocumentation`).
|
||||||
|
|
||||||
|
2. **README Files**
|
||||||
|
- Each root module in the project should contain its own `README` file, which provides context and instructions for the specific module.
|
||||||
|
- The `README` file must be in Markdown (`README.md`), Plain Text (`README.txt`), or have no extension (simply `README`).
|
||||||
|
- **Global documentation** for the entire project is held in the `docs/ManPages` directory.
|
||||||
|
|
||||||
|
3. **Test Directories**
|
||||||
|
- All root modules should contain a `tests` directory, located one level deep within the main module folder (e.g., `src/data-collection/tests`). This folder will house unit tests, integration tests, and other test resources relevant to the module.
|
||||||
|
|
||||||
|
4. **Data Directories**
|
||||||
|
- A `data/` directory in the project root holds static data files used across the entire project.
|
||||||
|
- If a `data/` directory exists within a `src` module, it may have specific functionality. Refer to the module’s `README` file for further clarification.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Example Directory Structure
|
||||||
|
|
||||||
|
```
|
||||||
|
MidasTechnologies/
|
||||||
|
│
|
||||||
|
├── src/
|
||||||
|
│ ├── neural-network/
|
||||||
|
│ │ ├── models.py # Neural network models
|
||||||
|
│ │ ├── training_script.py # Training scripts
|
||||||
|
│ │ └── ...
|
||||||
|
│ │
|
||||||
|
│ ├── data-collection/
|
||||||
|
│ │ ├── data_sources.py # Sources for data collection
|
||||||
|
│ │ ├── process_data.py # Data processing scripts
|
||||||
|
│ │ ├── tests/ # Contains unit tests, integration tests, and test resources
|
||||||
|
│ │ └── ...
|
||||||
|
│ │
|
||||||
|
│ ├── sentiment-analysis/
|
||||||
|
│ │ ├── analyze_sentiment.py # Sentiment analysis script
|
||||||
|
│ │ └── ...
|
||||||
|
│ │
|
||||||
|
│ ├── frontend/
|
||||||
|
│ │ ├── app.js # Frontend application code
|
||||||
|
│ │ └── ...
|
||||||
|
│ │
|
||||||
|
│ └── ...
|
||||||
|
│
|
||||||
|
├── docs/
|
||||||
|
│ ├── README.md # Project overview documentation
|
||||||
|
│ ├── BusinessDocumentation/ # Legal and business-related documentation
|
||||||
|
│ ├── ManPages/ # Global code documentation
|
||||||
|
│ └── PoliciesAndStandards/ # Markdown files on standards, policies, and guidelines
|
||||||
|
│
|
||||||
|
├── config/
|
||||||
|
│ ├── config.yaml # Main project configuration file
|
||||||
|
│ └── dev_config.yaml # Development-specific configuration
|
||||||
|
│
|
||||||
|
├── data/
|
||||||
|
│ └── sample_data.csv # Static data file example
|
||||||
|
│
|
||||||
|
├── scripts/
|
||||||
|
│ ├── setup.sh # Script to initialize the project setup
|
||||||
|
│ └── deploy.sh # Deployment script
|
||||||
|
│
|
||||||
|
├── examples/
|
||||||
|
│ ├── usage_example.py # Example usage of main project features
|
||||||
|
│ └── ...
|
||||||
|
│
|
||||||
|
└── assets/
|
||||||
|
├── logo.png # Project logo
|
||||||
|
└── favicon.ico # Icon for frontend
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Guidelines for Adding New Files
|
||||||
|
|
||||||
|
1. **Check the Existing Structure**
|
||||||
|
- Review the current directory structure before adding a new file to ensure you place it in the most relevant folder.
|
||||||
|
- Avoid creating redundant or deeply nested directories without a strong rationale.
|
||||||
|
|
||||||
|
2. **Follow Naming Conventions**
|
||||||
|
- Ensure that all files and directories follow the naming conventions specified above, keeping the structure consistent and predictable.
|
||||||
|
|
||||||
|
3. **Document New Directories**
|
||||||
|
- When adding a new folder that doesn’t fit existing patterns, include a `README.md` file or entry in the main project documentation within `docs/` to explain its purpose.
|
||||||
|
|
||||||
|
4. **Requirements for Documentation**
|
||||||
|
- All documentation files should be placed in the appropriate subdirectory within `docs/`.
|
||||||
|
- Markdown or text files should be used for documentation purposes, avoiding other file formats where possible.
|
||||||
|
|
||||||
846
PoliciesAndStandards/GitAndGithubStandards.md
Normal file
846
PoliciesAndStandards/GitAndGithubStandards.md
Normal file
@@ -0,0 +1,846 @@
|
|||||||
|
[#](#) Git and GitHub Standards
|
||||||
|
|
||||||
|
## Table of Contents
|
||||||
|
|
||||||
|
1. [Overview](#overview)
|
||||||
|
2. [Understanding Git and GitHub](#understanding-git-and-github)
|
||||||
|
3. [Branching Strategy](#branching-strategy)
|
||||||
|
4. [Branch Naming Conventions](#branch-naming-conventions)
|
||||||
|
5. [Commit Message Standards](#commit-message-standards)
|
||||||
|
6. [Code Review Policy](#code-review-policy)
|
||||||
|
7. [Best Practices for Using Git](#best-practices-for-using-git)
|
||||||
|
8. [Working with Pull Requests](#working-with-pull-requests)
|
||||||
|
9. [File-Path Standards](#file-path-standards)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
This document provides a comprehensive set of standards and best practices for using Git and GitHub within our development team. It covers foundational topics, including the branching strategy, branch naming conventions, commit message guidelines, code review policies, and collaboration workflows. The goal is to maintain a consistent and organized approach to version control, improve collaboration, ensure code quality, and streamline the development process.
|
||||||
|
|
||||||
|
The guidelines in this document are designed to help both new and experienced team members align with the company's coding and collaboration standards, facilitating smoother project management and code integrity.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Git and GitHub: A Comprehensive Guide
|
||||||
|
|
||||||
|
## Table of Contents
|
||||||
|
1. [Introduction](#introduction)
|
||||||
|
2. [Understanding Version Control](#understanding-version-control)
|
||||||
|
3. [Git Basics](#git-basics)
|
||||||
|
- [What is Git?](#what-is-git)
|
||||||
|
- [Core Concepts of Git](#core-concepts-of-git)
|
||||||
|
4. [Getting Started with Git](#getting-started-with-git)
|
||||||
|
- [Installing Git](#installing-git)
|
||||||
|
- [Configuring Git](#configuring-git)
|
||||||
|
5. [Git Essentials](#git-essentials)
|
||||||
|
- [Repositories](#repositories)
|
||||||
|
- [Staging and Committing](#staging-and-committing)
|
||||||
|
- [Branches and Merging](#branches-and-merging)
|
||||||
|
6. [Introduction to GitHub](#introduction-to-github)
|
||||||
|
- [What is GitHub?](#what-is-github)
|
||||||
|
- [Key Features of GitHub](#key-features-of-github)
|
||||||
|
7. [Working with Repositories on GitHub](#working-with-repositories-on-github)
|
||||||
|
8. [Git and GitHub Workflow](#git-and-github-workflow)
|
||||||
|
- [Forking and Cloning](#forking-and-cloning)
|
||||||
|
- [Pull Requests and Code Reviews](#pull-requests-and-code-reviews)
|
||||||
|
- [GitHub Issues and Project Management](#github-issues-and-project-management)
|
||||||
|
9. [Git Commands in Depth](#git-commands-in-depth)
|
||||||
|
10. [Advanced Git Techniques](#advanced-git-techniques)
|
||||||
|
- [Rebasing](#rebasing)
|
||||||
|
- [Cherry-Picking](#cherry-picking)
|
||||||
|
11. [Common Mistakes and How to Avoid Them](#common-mistakes-and-how-to-avoid-them)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Introduction
|
||||||
|
|
||||||
|
Git and GitHub are essential tools in the modern development landscape, allowing developers to manage changes, work collaboratively, and maintain robust codebases. Git is a distributed version control system that tracks code history, while GitHub enhances this by offering a platform for hosting, reviewing, and managing projects.
|
||||||
|
|
||||||
|
This guide delves into both Git and GitHub, providing an extensive overview that covers everything from beginner concepts to advanced techniques and command usage.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Understanding Version Control
|
||||||
|
|
||||||
|
**Version Control** is the backbone of any collaborative software development project. It allows teams to track code changes, collaborate seamlessly, and maintain a history of modifications to revert to previous versions when needed.
|
||||||
|
|
||||||
|
### Types of Version Control
|
||||||
|
|
||||||
|
1. **Local Version Control**: Simple, single-machine control, not suitable for team environments.
|
||||||
|
2. **Centralized Version Control (CVCS)**: Stores all file versions on a central server (e.g., SVN).
|
||||||
|
3. **Distributed Version Control (DVCS)**: Each team member has a full copy of the history and the latest version of the project, with Git being the most prominent DVCS.
|
||||||
|
|
||||||
|
Git is distributed, so it allows every developer to maintain a complete copy of the codebase on their own system, making collaboration more resilient and flexible.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Git Basics
|
||||||
|
|
||||||
|
### What is Git?
|
||||||
|
|
||||||
|
Git is a **distributed version control system** (DVCS) designed to handle projects of all sizes efficiently. It tracks changes to files, enabling developers to manage, review, and revert code.
|
||||||
|
|
||||||
|
### Core Concepts of Git
|
||||||
|
|
||||||
|
1. **Repository**: A collection of files, folders, and their complete revision history.
|
||||||
|
2. **Commit**: A snapshot of changes with a unique identifier (hash).
|
||||||
|
3. **Branch**: A separate line of development within a repository.
|
||||||
|
4. **Merge**: Combines changes from one branch into another, either to incorporate new features or resolve conflicts.
|
||||||
|
5. **Pull Request (PR)**: A request to merge changes from one branch into another with a code review.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Getting Started with Git
|
||||||
|
|
||||||
|
### Installing Git
|
||||||
|
|
||||||
|
To start using Git, install it on your local system:
|
||||||
|
- **Linux**: `sudo apt-get install git`
|
||||||
|
- **macOS**: `brew install git`
|
||||||
|
- **Windows**: Download from [Git’s website](https://git-scm.com/).
|
||||||
|
|
||||||
|
### Configuring Git
|
||||||
|
|
||||||
|
Set up your name and email, which will be attached to your commits:
|
||||||
|
```bash
|
||||||
|
git config --global user.name "Your Name"
|
||||||
|
git config --global user.email "your.email@example.com"
|
||||||
|
```
|
||||||
|
|
||||||
|
To verify configurations:
|
||||||
|
```bash
|
||||||
|
git config --list
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Git Essentials
|
||||||
|
|
||||||
|
### Repositories
|
||||||
|
|
||||||
|
A **repository** (repo) is the core structure of any Git project. It includes all project files, a history of changes, and branch information.
|
||||||
|
|
||||||
|
### Staging and Committing
|
||||||
|
|
||||||
|
1. **Staging**: The process of adding files to the staging area to prepare them for a commit.
|
||||||
|
2. **Committing**: Saves a snapshot of the staged changes in the repository with a unique identifier and message.
|
||||||
|
|
||||||
|
Basic workflow:
|
||||||
|
```bash
|
||||||
|
git add <filename> # Stage changes
|
||||||
|
git commit -m "Add description of changes" # Commit staged changes
|
||||||
|
```
|
||||||
|
|
||||||
|
### Branches and Merging
|
||||||
|
|
||||||
|
Branches let you create separate environments for development, allowing you to work on features without affecting the main codebase. Merging incorporates changes from one branch into another.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git branch <branch-name> # Create a new branch
|
||||||
|
git checkout <branch-name> # Switch to that branch
|
||||||
|
git merge <branch-name> # Merge branch into current branch
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Introduction to GitHub
|
||||||
|
|
||||||
|
### What is GitHub?
|
||||||
|
|
||||||
|
GitHub is a cloud-based platform for Git repositories, providing tools for collaboration, code review, and project management.
|
||||||
|
|
||||||
|
### Key Features of GitHub
|
||||||
|
|
||||||
|
- **Pull Requests**: Propose and discuss changes before merging.
|
||||||
|
- **Issues**: Track bugs and feature requests.
|
||||||
|
- **GitHub Actions**: Automate workflows for CI/CD.
|
||||||
|
- **Project Boards**: Visual task management using Kanban-style boards.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Working with Repositories on GitHub
|
||||||
|
|
||||||
|
1. **Creating a Repository**: Go to GitHub and create a new repository for your project.
|
||||||
|
2. **Cloning a Repository**: Copy a repository to your local machine with `git clone <repo-url>`.
|
||||||
|
3. **Syncing with Remote**: Use `git pull` to fetch and merge changes from the remote repo and `git push` to upload changes.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Git and GitHub Workflow
|
||||||
|
|
||||||
|
### Forking and Cloning
|
||||||
|
|
||||||
|
**Forking** allows you to create a copy of another user’s repository, letting you make changes without affecting the original. **Cloning** copies a remote repository to your local machine.
|
||||||
|
|
||||||
|
### Pull Requests and Code Reviews
|
||||||
|
|
||||||
|
- **Opening a PR**: After pushing changes to a branch, create a PR on GitHub to propose merging them into the main branch.
|
||||||
|
- **Code Reviews**: Collaborators can provide feedback, request changes, or approve the PR.
|
||||||
|
|
||||||
|
### GitHub Issues and Project Management
|
||||||
|
|
||||||
|
GitHub offers **Issues** to track development tasks and **Project Boards** to organize these issues visually.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Git Commands in Depth
|
||||||
|
|
||||||
|
### Working with Commits
|
||||||
|
|
||||||
|
- **View Commit History**: `git log` shows a detailed history of commits.
|
||||||
|
- **Viewing Differences**: `git diff` displays changes between commits or branches.
|
||||||
|
- **Amending a Commit**: Modify the last commit with `git commit --amend`.
|
||||||
|
|
||||||
|
### Branch Management
|
||||||
|
|
||||||
|
- **List Branches**: `git branch` shows all branches.
|
||||||
|
- **Delete a Branch**: `git branch -d <branch-name>` removes a local branch.
|
||||||
|
- **Rename a Branch**: `git branch -m <new-name>` renames the current branch.
|
||||||
|
|
||||||
|
### Merging Branches
|
||||||
|
|
||||||
|
Merging integrates changes from one branch to another. Use `git merge <branch-name>` to combine changes into the current branch.
|
||||||
|
|
||||||
|
### Rebasing
|
||||||
|
|
||||||
|
Rebasing applies commits from one branch onto another, maintaining a linear history:
|
||||||
|
```bash
|
||||||
|
git rebase <branch-name>
|
||||||
|
```
|
||||||
|
|
||||||
|
### Resetting and Reverting
|
||||||
|
|
||||||
|
- **Resetting**: Moves the repository to a previous state.
|
||||||
|
```bash
|
||||||
|
git reset --hard <commit-hash> # Discards all changes
|
||||||
|
git reset --soft <commit-hash> # Keeps changes in staging
|
||||||
|
```
|
||||||
|
- **Reverting**: Undoes a commit by creating a new commit.
|
||||||
|
```bash
|
||||||
|
git revert <commit-hash>
|
||||||
|
```
|
||||||
|
|
||||||
|
### Stashing
|
||||||
|
|
||||||
|
Stashing lets you save changes temporarily without committing:
|
||||||
|
```bash
|
||||||
|
git stash # Save changes
|
||||||
|
git stash apply # Restore stashed changes
|
||||||
|
```
|
||||||
|
|
||||||
|
### Cherry-Picking
|
||||||
|
|
||||||
|
Cherry-picking applies a specific commit from one branch onto another:
|
||||||
|
```bash
|
||||||
|
git cherry-pick <commit-hash>
|
||||||
|
```
|
||||||
|
|
||||||
|
### Synchronizing with Remotes
|
||||||
|
|
||||||
|
- **Fetch**: `git fetch` downloads updates from the remote repository.
|
||||||
|
- **Pull**: `git pull` combines `fetch` and `merge`.
|
||||||
|
- **Push**: `git push` uploads local changes to the remote repository.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Advanced Git Techniques
|
||||||
|
|
||||||
|
### Git Aliases
|
||||||
|
|
||||||
|
Aliases can simplify complex Git commands:
|
||||||
|
```bash
|
||||||
|
git config --global alias.st status
|
||||||
|
git config --global alias.cm commit
|
||||||
|
```
|
||||||
|
|
||||||
|
### Interactive Rebase
|
||||||
|
|
||||||
|
Interactive rebasing allows you to reorder, squash, or edit commits:
|
||||||
|
```bash
|
||||||
|
git rebase -i <base-commit>
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Common Mistakes and How to Avoid Them
|
||||||
|
|
||||||
|
### Forgetting to Stage Changes
|
||||||
|
|
||||||
|
If you forget to `git add` your changes, they won’t be included in your commit. Always check with `git status` before committing.
|
||||||
|
|
||||||
|
### Overwriting History with Rebase
|
||||||
|
|
||||||
|
Rebasing can rewrite history, so it’s recommended to avoid it on branches shared with others. Only rebase
|
||||||
|
|
||||||
|
branches that haven’t been pushed or that you’re working on independently.
|
||||||
|
|
||||||
|
### Ignoring Merge Conflicts
|
||||||
|
|
||||||
|
When merging branches, conflicts may arise. Don’t skip or ignore these! Use a merge tool or manually resolve conflicts, and make sure to commit the resolved changes.
|
||||||
|
|
||||||
|
### Accidental Commits to the Wrong Branch
|
||||||
|
|
||||||
|
Switching branches without committing or stashing changes can result in accidental commits. Always check your branch with `git branch` before committing and use `git stash` to save uncommitted changes if you need to switch.
|
||||||
|
|
||||||
|
### Pushing Sensitive Information
|
||||||
|
|
||||||
|
Never commit sensitive data like passwords, API keys, or credentials. Use a `.gitignore` file to exclude sensitive files and directories:
|
||||||
|
```bash
|
||||||
|
echo "config.json" >> .gitignore
|
||||||
|
```
|
||||||
|
|
||||||
|
### Force Pushing
|
||||||
|
|
||||||
|
Using `git push --force` can overwrite others' work. Only use `--force` when absolutely necessary, and communicate with your team beforehand. I have removed `--force` capabilitys on the github
|
||||||
|
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
# Branching Structure and Naming Conventions
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
This document establishes standards for creating, naming, and managing branches within our repository. Following these guidelines will ensure a clean, organized codebase, making it easier for the team to manage code changes, facilitate collaboration, and maintain clarity across multiple projects.
|
||||||
|
|
||||||
|
## Table of Contents
|
||||||
|
1. [Branch Structure](#branch-structure)
|
||||||
|
- [Main Branch](#main-branch)
|
||||||
|
- [Development Branch](#development-branch)
|
||||||
|
- [Feature and Ad-Hoc Branches](#feature-and-ad-hoc-branches)
|
||||||
|
2. [Branch Naming Conventions](#branch-naming-conventions)
|
||||||
|
- [Prefixes](#prefixes)
|
||||||
|
- [Examples](#examples)
|
||||||
|
3. [File Naming Standards](#file-naming-standards)
|
||||||
|
4. [Workflow for Contributors](#workflow-for-contributors)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Branch Structure
|
||||||
|
|
||||||
|
Our repository follows a structured branching system with two main branches, `main` and `dev`, along with various **feature** and **ad-hoc branches** off `dev` for specific tasks. **All branches off `dev` should be named according to the conventions defined in this document.**
|
||||||
|
|
||||||
|
### 1. `main` Branch
|
||||||
|
|
||||||
|
- **Purpose**: The `main` branch contains **production-ready code**. This is where stable, tested code resides and reflects the latest release version of the codebase.
|
||||||
|
- **Access**: Only project maintainers can directly merge code into `main`.
|
||||||
|
- **Merges**: Code merges into `main` should always come from `dev` after passing code reviews and tests.
|
||||||
|
- **Protection**: This branch is protected by branch rules, requiring code reviews and successful checks before merging.
|
||||||
|
|
||||||
|
### 2. `dev` Branch
|
||||||
|
|
||||||
|
- **Purpose**: The `dev` branch is a **staging branch for testing** new features, bug fixes, and documentation updates before they reach `main`.
|
||||||
|
- **Access**: All contributors can create branches off `dev` for their work. Contributors are not allowed to push directly to `dev`; all changes must be submitted via pull requests.
|
||||||
|
- **Merges**: All feature, bugfix, documentation, and test branches should be merged back into `dev` after review and testing.
|
||||||
|
|
||||||
|
### 3. Feature and Ad-Hoc Branches
|
||||||
|
|
||||||
|
- **Purpose**: Branches off `dev` are used for specific features, bug fixes, testing updates, and documentation changes. These branches must follow the naming conventions detailed in the following section.
|
||||||
|
- **Lifecycle**: Feature and ad-hoc branches are created for individual tasks and are short-lived. Once their purpose is completed, they are merged into `dev` and deleted.
|
||||||
|
- **Permissions**: Contributors create, work on, and manage these branches off `dev` but **must submit pull requests (PRs) for all changes to `dev`**.
|
||||||
|
|
||||||
|
> **Note**: Only the GitHub repository manager may deviate from these conventions.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Branch Naming Conventions
|
||||||
|
|
||||||
|
To maintain organization and readability, all branches off `dev` must follow these naming conventions. Standard prefixes indicate the branch's purpose and scope, providing clarity to other contributors.
|
||||||
|
|
||||||
|
### General Rules
|
||||||
|
|
||||||
|
- **Lowercase Only**: Branch names must be in lowercase.
|
||||||
|
- **Hyphens for Separation**: Use hyphens (`-`) to separate words within a branch name.
|
||||||
|
- **Descriptive Names**: Branch names should indicate the purpose of the branch (e.g., feature, bugfix) and include an identifier if relevant.
|
||||||
|
- **Reference to Issue/Feature Numbers**: When applicable, include a reference to the GitHub issue number.
|
||||||
|
|
||||||
|
### Prefixes
|
||||||
|
|
||||||
|
| Prefix | Purpose | Example |
|
||||||
|
|--------------|-------------------------------------------|-------------------------------------------|
|
||||||
|
| `feature/` | For new features or enhancements | `feature/user-authentication` |
|
||||||
|
| `bugfix/` | For fixing known bugs or issues | `bugfix/1023-login-error` |
|
||||||
|
| `docs/` | For documentation updates and additions | `docs/api-endpoints-documentation` |
|
||||||
|
| `test/` | For changes or additions to tests | `test/add-unit-tests` |
|
||||||
|
| `hotfix/` | For critical fixes that need immediate attention in `dev` or `main` | `hotfix/production-fix-login-error` |
|
||||||
|
|
||||||
|
> **Note**: All prefixes indicate branches off `dev` and should not directly branch from `main` without repository manager approval.
|
||||||
|
|
||||||
|
### Branch Names, Scenarios and Examples
|
||||||
|
|
||||||
|
| Purpose | Branch Name | Description |
|
||||||
|
|-------------------|------------------------------------|--------------------------------------------|
|
||||||
|
| New Feature | `feature/user-registration` | Adds user registration functionality |
|
||||||
|
| Bug Fix | `bugfix/215-api-authorization` | Fixes authorization issue on API requests |
|
||||||
|
| Documentation | `docs/setup-instructions` | Adds setup instructions to documentation |
|
||||||
|
| Testing | `test/integration-test-api` | Adds integration tests for API endpoints |
|
||||||
|
| Hotfix | `hotfix/cache-issue` | Urgent fix for cache-related issue |
|
||||||
|
|
||||||
|
When working on specific aspects of the project, contributors should use designated branches to ensure consistency and organization. **All branches, unless specified, must be created off the `dev` branch**. Below are common scenarios and the appropriate branches for each task:
|
||||||
|
|
||||||
|
#### 1. **Adding a Web Scraper**
|
||||||
|
|
||||||
|
- **Branch**: `DataCollection` (branch off `dev`)
|
||||||
|
- **Process**:
|
||||||
|
- Begin by switching to the `dev` branch:
|
||||||
|
```bash
|
||||||
|
git checkout dev
|
||||||
|
git pull origin dev
|
||||||
|
```
|
||||||
|
- Check out the `DataCollection` branch:
|
||||||
|
```bash
|
||||||
|
git checkout DataCollection
|
||||||
|
```
|
||||||
|
- If `DataCollection` does not exist, create it off `dev`:
|
||||||
|
```bash
|
||||||
|
git checkout -b DataCollection dev
|
||||||
|
git push -u origin DataCollection
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 2. **Adding Documentation**
|
||||||
|
|
||||||
|
- **Branch**: `docs` (branch off `dev`)
|
||||||
|
- **Process**:
|
||||||
|
- Switch to the `dev` branch and pull the latest updates:
|
||||||
|
```bash
|
||||||
|
git checkout dev
|
||||||
|
git pull origin dev
|
||||||
|
```
|
||||||
|
- Check out the `docs` branch:
|
||||||
|
```bash
|
||||||
|
git checkout docs
|
||||||
|
```
|
||||||
|
- If `docs` does not exist, create it off `dev`:
|
||||||
|
```bash
|
||||||
|
git checkout -b docs dev
|
||||||
|
git push -u origin docs
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 3. **Adding Business Files**
|
||||||
|
|
||||||
|
- **Branch**: `businessfiles` (branch off `dev`)
|
||||||
|
- **Process**:
|
||||||
|
- Ensure you’re working from the latest `dev` updates:
|
||||||
|
```bash
|
||||||
|
git checkout dev
|
||||||
|
git pull origin dev
|
||||||
|
```
|
||||||
|
- Check out the `businessfiles` branch:
|
||||||
|
```bash
|
||||||
|
git checkout businessfiles
|
||||||
|
```
|
||||||
|
- If `businessfiles` does not exist, create it off `dev`:
|
||||||
|
```bash
|
||||||
|
git checkout -b businessfiles dev
|
||||||
|
git push -u origin businessfiles
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 4. **Bug Fixes**
|
||||||
|
|
||||||
|
- **Branch**: `bugfix` (branch off `dev`)
|
||||||
|
- **Process**:
|
||||||
|
- Start from the latest `dev` updates:
|
||||||
|
```bash
|
||||||
|
git checkout dev
|
||||||
|
git pull origin dev
|
||||||
|
```
|
||||||
|
- Check out the `bugfix` branch:
|
||||||
|
```bash
|
||||||
|
git checkout bugfix
|
||||||
|
```
|
||||||
|
- If `bugfix` does not exist, create it:
|
||||||
|
```bash
|
||||||
|
git checkout -b bugfix dev
|
||||||
|
git push -u origin bugfix
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 5. **Hotfixes**
|
||||||
|
|
||||||
|
- **Branch**: `hotfix` (branch off `dev`)
|
||||||
|
- **Process**:
|
||||||
|
- Ensure your local `dev` branch is up to date:
|
||||||
|
```bash
|
||||||
|
git checkout dev
|
||||||
|
git pull origin dev
|
||||||
|
```
|
||||||
|
- Check out the `hotfix` branch:
|
||||||
|
```bash
|
||||||
|
git checkout hotfix
|
||||||
|
```
|
||||||
|
- If `hotfix` does not exist, create it:
|
||||||
|
```bash
|
||||||
|
git checkout -b hotfix dev
|
||||||
|
git push -u origin hotfix
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 6. **Testing**
|
||||||
|
|
||||||
|
- **Branch**: `testing` (branch off `dev`)
|
||||||
|
- **Process**:
|
||||||
|
- Start from the latest `dev` branch:
|
||||||
|
```bash
|
||||||
|
git checkout dev
|
||||||
|
git pull origin dev
|
||||||
|
```
|
||||||
|
- Check out the `testing` branch:
|
||||||
|
```bash
|
||||||
|
git checkout testing
|
||||||
|
```
|
||||||
|
- If `testing` does not exist, create it:
|
||||||
|
```bash
|
||||||
|
git checkout -b testing dev
|
||||||
|
git push -u origin testing
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 7. **Feature Development**
|
||||||
|
|
||||||
|
- **Branch**: `feature/feature-name` (branch off `dev`)
|
||||||
|
- **Process**:
|
||||||
|
- Before starting, always check if a specific feature branch exists.
|
||||||
|
- If no specific branch exists, create a new feature branch off `dev`:
|
||||||
|
```bash
|
||||||
|
git checkout dev
|
||||||
|
git pull origin dev
|
||||||
|
git checkout -b feature/your-feature-name dev
|
||||||
|
git push -u origin feature/your-feature-name
|
||||||
|
```
|
||||||
|
- **Note**: Follow the naming conventions for all feature branches and verify it branches off `dev`.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Handling Merge Conflicts
|
||||||
|
|
||||||
|
Merge conflicts can occur when changes in two branches affect the same lines of code. Here are best practices and commands to resolve them effectively.
|
||||||
|
|
||||||
|
### Steps to Resolve Merge Conflicts
|
||||||
|
|
||||||
|
1. **Identify the Conflict**:
|
||||||
|
- When attempting to merge, Git will notify you of conflicts. Use the `git status` command to identify files with conflicts:
|
||||||
|
```bash
|
||||||
|
git status
|
||||||
|
```
|
||||||
|
|
||||||
|
2. **Open and Review Conflicting Files**:
|
||||||
|
- Open the conflicting files in an editor. Git marks conflicts with `<<<<<<<`, `=======`, and `>>>>>>>`.
|
||||||
|
- Manually review the changes, decide which version to keep, or combine changes where necessary.
|
||||||
|
|
||||||
|
3. **Mark Conflicts as Resolved**:
|
||||||
|
- After resolving conflicts in each file, mark it as resolved:
|
||||||
|
```bash
|
||||||
|
git add <file-name>
|
||||||
|
```
|
||||||
|
|
||||||
|
4. **Complete the Merge**:
|
||||||
|
- Once all conflicts are resolved, commit the merge:
|
||||||
|
```bash
|
||||||
|
git commit
|
||||||
|
```
|
||||||
|
|
||||||
|
5. **Push the Resolved Branch**:
|
||||||
|
- After committing, push the branch to the remote repository:
|
||||||
|
```bash
|
||||||
|
git push
|
||||||
|
```
|
||||||
|
|
||||||
|
### Best Practices for Conflict Resolution
|
||||||
|
|
||||||
|
- **Resolve Locally**: If possible, resolve conflicts on your local machine to minimize errors and ensure all changes are reviewed.
|
||||||
|
- **Communicate with Team Members**: If the conflict is complex or affects significant code, communicate with the involved team members for clarity and to avoid overwriting important changes.
|
||||||
|
- **Use Git Tools for Assistance**: Tools like `git diff` and `git log` are helpful for understanding changes in context. Additionally, many IDEs offer merge tools that visualize conflicts.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## File Naming Standards
|
||||||
|
|
||||||
|
To maintain a consistent and organized structure, file names should follow these standards based on file type.
|
||||||
|
|
||||||
|
### Documentation Files
|
||||||
|
|
||||||
|
- **Capitalized Case**: Use Capitalized Case for documentation files (e.g., `GitAndGitHubStandards.md`).
|
||||||
|
- **Avoid Special Characters**: Do not use spaces or special characters.
|
||||||
|
- **Location**: Documentation related to each project should be stored within a `docs/` or `documentation/` directory in the root of each project.
|
||||||
|
|
||||||
|
### Code Files
|
||||||
|
|
||||||
|
- **Lowercase with Underscores**: Use lowercase names with underscores (e.g., `user_authentication.py`).
|
||||||
|
- **No Spaces or Special Characters**: Avoid spaces or special characters in code file names.
|
||||||
|
- **Descriptive Names**: Name files according to their primary function or feature (e.g., `data_processing.py` for data processing functions).
|
||||||
|
|
||||||
|
### Directory Naming
|
||||||
|
|
||||||
|
- **Organization by Function**: Directories should be organized by functionality (e.g., `models/`, `controllers/`, `tests/`).
|
||||||
|
- **Standard Directory Names**: Keep directory names simple and standardized to make navigation intuitive.
|
||||||
|
|
||||||
|
> **Example Directory Structure**:
|
||||||
|
```
|
||||||
|
project_root/
|
||||||
|
│
|
||||||
|
├── docs/
|
||||||
|
│ └── README.md
|
||||||
|
├── src/
|
||||||
|
│ ├── models/
|
||||||
|
│ ├── controllers/
|
||||||
|
│ ├── utils/
|
||||||
|
│ └── main.py
|
||||||
|
└── tests/
|
||||||
|
├── test_data_processing.py
|
||||||
|
└── test_user_authentication.py
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Workflow for Contributors
|
||||||
|
|
||||||
|
This workflow ensures consistent practices across contributors for setting up branches, working locally, and pushing changes.
|
||||||
|
|
||||||
|
### Step 0: Clone the Repository
|
||||||
|
|
||||||
|
Clone the repository to your local environment if you haven’t already.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git clone git@github.com:MiadTechnologiesLCC/MidasTechnologies.git
|
||||||
|
cd MidasTechnologies
|
||||||
|
```
|
||||||
|
|
||||||
|
### Step 1: Set Up Branch Tracking
|
||||||
|
|
||||||
|
Ensure you have the latest branches set up locally:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git fetch origin
|
||||||
|
```
|
||||||
|
|
||||||
|
### Step 2: Check Out `dev` for New Work
|
||||||
|
|
||||||
|
Always base new work off the `dev` branch:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git checkout dev
|
||||||
|
git pull origin dev # Ensure dev is up to date
|
||||||
|
```
|
||||||
|
|
||||||
|
### Step 3: Create a New Branch Off `dev`
|
||||||
|
|
||||||
|
Create a new branch for your work based on the type of work you’re doing (feature, bugfix, docs, etc.). Follow the branch naming conventions.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git checkout -b feature/new-feature-name dev
|
||||||
|
```
|
||||||
|
|
||||||
|
### Step 4: Make and Commit Changes
|
||||||
|
|
||||||
|
As you work, make regular commits with clear, descriptive messages following our commit message standards:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git add .
|
||||||
|
git commit -m "feat: add feature description"
|
||||||
|
```
|
||||||
|
|
||||||
|
### Step 5: Push the Branch to GitHub
|
||||||
|
|
||||||
|
When ready, push your branch to GitHub:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git push -u origin feature/new-feature-name
|
||||||
|
```
|
||||||
|
|
||||||
|
### Step 6: Create a Pull Request
|
||||||
|
|
||||||
|
- **Create PR**: Go to GitHub and create a pull request (PR) from your feature branch into `dev`.
|
||||||
|
- **Review Request**: Assign reviewers as necessary and respond to feedback.
|
||||||
|
- **Ensure Compliance**: Confirm that the PR adheres to all required tests, checks, and naming conventions before approval and merging.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Common Mistakes to Avoid
|
||||||
|
|
||||||
|
1. **Directly Branching Off `main`**: All branches should be created off `dev` unless given explicit permission from the repository manager.
|
||||||
|
2. **Inconsistent Naming**: Stick to prefix conventions and lowercase names with hyphens to maintain clarity.
|
||||||
|
3. **Forgetting to Pull `dev` Updates**: Always pull the latest changes from `dev` to avoid conflicts.
|
||||||
|
4. **Pushing to `dev` Without a PR**: Changes should never be pushed directly to `dev`; submit all changes via a pull request.
|
||||||
|
5. **Improper File Naming**: Follow naming standards strictly, with documentation files in Capitalized Case and code files in lowercase with underscores.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Code Review Policy
|
||||||
|
|
||||||
|
## Table of Contents
|
||||||
|
|
||||||
|
1. [Code Review Workflow](#code-review-workflow)
|
||||||
|
- [Opening a Pull Request](#opening-a-pull-request)
|
||||||
|
- [Review Assignment and Timeline](#review-assignment-and-timeline)
|
||||||
|
2. [Working with Pull Requests](#working-with-pull-requests)
|
||||||
|
- [Create a PR for Each Feature](#create-a-pr-for-each-feature)
|
||||||
|
- [Resolve All Conversations Before Merging](#resolve-all-conversations-before-merging)
|
||||||
|
- [Merge Protocol](#merge-protocol)
|
||||||
|
3. [Code Review Focus Areas](#code-review-focus-areas)
|
||||||
|
- [Code Quality and Consistency](#code-quality-and-consistency)
|
||||||
|
- [Functionality and Completeness](#functionality-and-completeness)
|
||||||
|
- [Testing and Coverage](#testing-and-coverage)
|
||||||
|
- [Security and Performance](#security-and-performance)
|
||||||
|
- [Documentation and Commenting](#documentation-and-commenting)
|
||||||
|
- [File Structure and Organization](#file-structure-and-organization)
|
||||||
|
4. [Reviewer Responsibilities](#reviewer-responsibilities)
|
||||||
|
5. [Contributor Responsibilities](#contributor-responsibilities)
|
||||||
|
6. [Final Approval and Merging Process](#final-approval-and-merging-process)
|
||||||
|
- [Approval Requirements](#approval-requirements)
|
||||||
|
- [Merging to Dev or Main](#merging-to-dev-or-main)
|
||||||
|
- [Final Checks Before Merging](#final-checks-before-merging)
|
||||||
|
7. [Common Code Review Mistakes to Avoid](#common-code-review-mistakes-to-avoid)
|
||||||
|
8. [Post-Review Responsibilities](#post-review-responsibilities)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Code Review Workflow
|
||||||
|
|
||||||
|
### Opening a Pull Request
|
||||||
|
|
||||||
|
When creating a Pull Request (PR), adhere to the following guidelines to ensure a smooth and productive review process:
|
||||||
|
|
||||||
|
1. **Branch Source**:
|
||||||
|
- PRs must originate from designated branches, such as **feature**, **bugfix**, **hotfix**, or **docs**, following the [Branch Naming Conventions](./Branch%20Naming%20Conventions.md).
|
||||||
|
- PRs should generally target the `dev` branch, while only production-ready PRs may target the `main` branch. Merges to `main` are restricted to project maintainers to maintain code quality.
|
||||||
|
|
||||||
|
2. **Title & Description**:
|
||||||
|
- Use a clear and concise title for each PR.
|
||||||
|
- Provide a thorough description, covering context, scope, and any relevant issues or implementation details.
|
||||||
|
- Clearly indicate any special requirements for deployment, breaking changes, or additional dependencies.
|
||||||
|
|
||||||
|
3. **File Organization**:
|
||||||
|
- Follow the [# file-path standards](#file-path-standards) to ensure all new files and directories are structured for efficient navigation and ease of maintenance.
|
||||||
|
|
||||||
|
### Review Assignment and Timeline
|
||||||
|
|
||||||
|
- Assign PRs to experienced reviewers in relevant code areas. For complex changes, multiple reviewers may be required.
|
||||||
|
- Use GitHub tags to notify reviewers, aiming for a 24–48 hour turnaround on PR reviews to support an efficient workflow.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Working with Pull Requests
|
||||||
|
|
||||||
|
### Create a PR for Each Feature
|
||||||
|
|
||||||
|
- Link the PR to any associated issues or tasks for traceability.
|
||||||
|
- Request a review from team members knowledgeable about the relevant functionality.
|
||||||
|
|
||||||
|
### Resolve All Conversations Before Merging
|
||||||
|
|
||||||
|
- Address all reviewer feedback and mark conversations as resolved before final approval.
|
||||||
|
- If substantial modifications are made in response to feedback, re-request a review to ensure consensus.
|
||||||
|
|
||||||
|
### Merge Protocol
|
||||||
|
|
||||||
|
- **PRs into `dev`**: These require at least one reviewer’s approval.
|
||||||
|
- **PRs from `dev` to `main`**: Limited to the project maintainer, with thorough testing and final approval required to ensure the stability of `main`.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Code Review Focus Areas
|
||||||
|
|
||||||
|
Reviewers should concentrate on these critical areas to ensure quality, functionality, and maintainability across the codebase:
|
||||||
|
|
||||||
|
### Code Quality and Consistency
|
||||||
|
|
||||||
|
- Follow our [Coding Standards](./Coding%20Standards.md) for readability, maintainability, and consistency.
|
||||||
|
- Maintain modularity and avoid redundancy, using existing functions or libraries where appropriate.
|
||||||
|
- Confirm adherence to language-specific standards (e.g., PEP8 for Python).
|
||||||
|
|
||||||
|
### Functionality and Completeness
|
||||||
|
|
||||||
|
- Verify that the code performs as intended without regressions.
|
||||||
|
- Ensure all specified use cases, including edge cases, are covered. Seek clarification from the contributor if requirements are ambiguous.
|
||||||
|
|
||||||
|
### Testing and Coverage
|
||||||
|
|
||||||
|
- Check for sufficient test coverage, ideally at least 85%, with a preference for automated tests.
|
||||||
|
- Ensure all tests, including unit, integration, and end-to-end (E2E) tests, pass successfully.
|
||||||
|
- Confirm compliance with the [# file-path standards](#file-path-standards) for consistency in test file organization.
|
||||||
|
|
||||||
|
### Security and Performance
|
||||||
|
|
||||||
|
- Assess for potential security vulnerabilities, especially in areas related to data handling, user authentication, or API calls.
|
||||||
|
- Evaluate performance, suggesting improvements if any bottlenecks or inefficiencies are detected.
|
||||||
|
|
||||||
|
### Documentation and Commenting
|
||||||
|
|
||||||
|
- All public functions, classes, and methods should have clear docstrings, following our [Documentation Standards](./Documentation%20Standards.md).
|
||||||
|
- Complex logic should be well-commented to explain non-standard approaches or optimizations.
|
||||||
|
- Verify updates to user or developer documentation when relevant.
|
||||||
|
|
||||||
|
### File Structure and Organization
|
||||||
|
|
||||||
|
- Ensure new files and directories align with the [# file-path standards](#file-path-standards) to maintain logical structure.
|
||||||
|
- Check that file organization is consistent with the established hierarchy, supporting ease of access and maintenance.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Reviewer Responsibilities
|
||||||
|
|
||||||
|
Reviewers are accountable for providing timely, constructive, and actionable feedback:
|
||||||
|
|
||||||
|
- **Timely Feedback**: Complete PR reviews within 24–48 hours whenever possible.
|
||||||
|
- **Constructive Feedback**: Offer specific, actionable suggestions for improvements, avoiding vague criticism.
|
||||||
|
- **Approval Process**:
|
||||||
|
- Only approve PRs if they meet quality standards and have no outstanding issues.
|
||||||
|
- Request changes if additional work is needed or standards are not met.
|
||||||
|
- Ensure compliance with the [# file-path standards](#file-path-standards), naming conventions, and coding guidelines.
|
||||||
|
- **Professionalism**: Maintain respect and clarity in all feedback, focusing on improvement.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Contributor Responsibilities
|
||||||
|
|
||||||
|
Contributors are responsible for ensuring their code is up to standard prior to submission:
|
||||||
|
|
||||||
|
1. **Self-Review**: Conduct a thorough self-review, verifying clarity, standards compliance, and testing.
|
||||||
|
2. **Feedback Response**: Address all reviewer comments and make necessary changes, re-requesting a review if major adjustments are made.
|
||||||
|
3. **Conversation Resolution**: Mark all feedback conversations as resolved before requesting final approval.
|
||||||
|
4. **Commit Standards**: Follow [Commit Message Standards](./Commit%20Message%20Standards.md) to keep commit messages informative, consistent, and concise.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Final Approval and Merging Process
|
||||||
|
|
||||||
|
### Approval Requirements
|
||||||
|
|
||||||
|
- PRs must have at least one reviewer’s approval, with additional reviewers for complex or high-risk changes.
|
||||||
|
- Only project maintainers or designated personnel may approve and merge PRs into `main`.
|
||||||
|
|
||||||
|
### Merging to Dev or Main
|
||||||
|
|
||||||
|
- **Merging into `dev`**: Contributors may merge PRs after at least one review and approval.
|
||||||
|
- **Merging into `main`**: Restricted to maintainers; requires extensive testing to confirm production readiness.
|
||||||
|
|
||||||
|
### Final Checks Before Merging
|
||||||
|
|
||||||
|
- Ensure all tests pass and the latest code changes are integrated into the PR.
|
||||||
|
- Verify the [# file-path standards](#file-path-standards) are followed and the directory structure is organized.
|
||||||
|
- Update the PR description with any final notes or additional context.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Common Code Review Mistakes to Avoid
|
||||||
|
|
||||||
|
1. **Skipping Self-Review**: Self-review reduces back-and-forth and helps identify issues preemptively.
|
||||||
|
2. **Insufficient Test Coverage**: Lack of comprehensive tests can lead to unexpected bugs. Aim to cover all use cases and edge scenarios.
|
||||||
|
3. **Premature Approval**: Ensure understanding of the PR’s purpose and functionality before approving.
|
||||||
|
4. **File and Path Non-Compliance**: Files should adhere to naming and path standards as detailed in [# file-path standards](#file-path-standards).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Post-Review Responsibilities
|
||||||
|
|
||||||
|
### Continuous Improvement
|
||||||
|
|
||||||
|
- Identify opportunities for process improvement based on challenges encountered during the review.
|
||||||
|
- Record valuable lessons, significant changes, or patterns in a shared knowledge base for future use.
|
||||||
|
|
||||||
|
### Follow-up Tasks
|
||||||
|
|
||||||
|
- Log any remaining issues or future improvements as GitHub issues for future sprints.
|
||||||
|
- Update documentation when significant changes impact user guides, API references, or other project docs.
|
||||||
|
|
||||||
|
### Retrospective and Feedback
|
||||||
|
|
||||||
|
- Periodically evaluate the review process's effectiveness, gathering feedback to refine workflow, collaboration, and code quality practices.
|
||||||
|
|
||||||
156
PoliciesAndStandards/LatexForBeginners.md
Normal file
156
PoliciesAndStandards/LatexForBeginners.md
Normal file
@@ -0,0 +1,156 @@
|
|||||||
|
# LaTex Guide For Beginners
|
||||||
|
|
||||||
|
## Introduction
|
||||||
|
|
||||||
|
LaTeX is a document preparation system used to produce professional-looking documents. Unlike traditional word processors, LaTeX emphasizes content over appearance by allowing the authors to focus on document structure while typesetting is handled automaticaly. LaTeX is particularly suited for creating long, structured documents and typesetting equations.
|
||||||
|
|
||||||
|
> **Key Features of LaTeX**
|
||||||
|
> - Produces high-qualty documents.
|
||||||
|
> - Ideal for academic papers, documents with mathematical equations, theses, and technical documents.
|
||||||
|
> - Typesets mathematical equations with precision.
|
||||||
|
|
||||||
|
## Compiling LaTeX Files:
|
||||||
|
|
||||||
|
To compile a `.text` file into a readable format like a `.pdf`, the command line or a LaTeX editor can be used.
|
||||||
|
|
||||||
|
```Bash
|
||||||
|
# Compile a LaTeX file to a .dvi file
|
||||||
|
latex [filename].tex
|
||||||
|
> output is [filename].dvi
|
||||||
|
|
||||||
|
# Compile a LaTeX file directly to a .pdf
|
||||||
|
pdflatex [filename].tex
|
||||||
|
> output is [filename].pdf
|
||||||
|
|
||||||
|
# Convert a .dvi file to a PostScript (.ps) file
|
||||||
|
dvips -o [filename].ps [filename].dvi
|
||||||
|
> output is [filename].ps
|
||||||
|
|
||||||
|
# Convert a .dvi file to a .pdf
|
||||||
|
dvipdfm [filename].dvi
|
||||||
|
```
|
||||||
|
|
||||||
|
--
|
||||||
|
|
||||||
|
## Essentials of LaTeX
|
||||||
|
|
||||||
|
### Document Structure
|
||||||
|
|
||||||
|
Every LaTeX document starts with a `\documentclass` declaration, specifying the document type, followed by content wrapped in a `document` environment:
|
||||||
|
|
||||||
|
```latex
|
||||||
|
\documentclass[a4paper,12pt]{article}
|
||||||
|
\begin{document}
|
||||||
|
\title{My First Document}
|
||||||
|
\author{Author Name}
|
||||||
|
\date{\today}
|
||||||
|
\maketitle
|
||||||
|
\end{document}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Sections and Labels
|
||||||
|
|
||||||
|
Divide your document into sections for better organization:
|
||||||
|
|
||||||
|
```latex
|
||||||
|
\section{Introduction}
|
||||||
|
This is the introduction.
|
||||||
|
|
||||||
|
\section{Methods}
|
||||||
|
\subsection{Step 1}
|
||||||
|
The first step.
|
||||||
|
|
||||||
|
\section{Results}
|
||||||
|
Results are shown in Figure \ref{fig:example}.
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Creating Tables
|
||||||
|
|
||||||
|
To create a table, use the `tabular` environment:
|
||||||
|
|
||||||
|
```latex
|
||||||
|
\begin{tabular}{|l|c|r|}
|
||||||
|
\hline
|
||||||
|
Item & Quantity & Price (\$) \\
|
||||||
|
\hline
|
||||||
|
Nails & 500 & 0.34 \\
|
||||||
|
Wooden boards & 100 & 4.00 \\
|
||||||
|
Bricks & 240 & 11.50 \\
|
||||||
|
\hline
|
||||||
|
\end{tabular}
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Adding Figures
|
||||||
|
|
||||||
|
To include images, add the `graphicx` package in the preamble and use the `figure` environment:
|
||||||
|
|
||||||
|
```latex
|
||||||
|
\usepackage{graphicx}
|
||||||
|
|
||||||
|
\begin{figure}[h]
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=0.8\textwidth]{example.png}
|
||||||
|
\caption{An example image}
|
||||||
|
\label{fig:example}
|
||||||
|
\end{figure}
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Writing Equations
|
||||||
|
|
||||||
|
LaTeX provides multiple ways to write mathematical equations:
|
||||||
|
|
||||||
|
- **Inline equations:** `$E = mc^2$`
|
||||||
|
- **Displayed equations:**
|
||||||
|
```latex
|
||||||
|
\begin{equation}
|
||||||
|
E = mc^2
|
||||||
|
\end{equation}
|
||||||
|
```
|
||||||
|
|
||||||
|
- **Equation arrays:**
|
||||||
|
```latex
|
||||||
|
\begin{eqnarray}
|
||||||
|
a & = & b + c \\
|
||||||
|
& = & y - z
|
||||||
|
\end{eqnarray}
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## References
|
||||||
|
|
||||||
|
LaTeX can manage references and citations using BibTeX. Create a `.bib` file with references:
|
||||||
|
|
||||||
|
```bibtex
|
||||||
|
@article{example,
|
||||||
|
Author = {Author Name},
|
||||||
|
Title = {Title of the Paper},
|
||||||
|
Journal = {Journal Name},
|
||||||
|
Year = {2021}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Include the bibliography in your `.tex` file:
|
||||||
|
|
||||||
|
```latex
|
||||||
|
\bibliographystyle{plain}
|
||||||
|
\bibliography{references}
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Further Reading
|
||||||
|
|
||||||
|
- [LaTeX Project](http://www.latex-project.org/)
|
||||||
|
- [LaTeX Wikibook](http://en.wikibooks.org/wiki/LaTeX/)
|
||||||
|
- [Not So Short Introduction to LaTeX](http://ctan.tug.org/tex-archive/info/lshort/english/lshort.pdf)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*Note: This guide is based on information from the "LaTeX for Beginners Workbook" (Edition 5, March 2014) and additional command-line instructions.*
|
||||||
83
PoliciesAndStandards/README.md
Normal file
83
PoliciesAndStandards/README.md
Normal file
@@ -0,0 +1,83 @@
|
|||||||
|
# Policies and Standards
|
||||||
|
|
||||||
|
Welcome to the **Policies and Standards** directory! This section contains critical documentation outlining the standards, practices, and workflows that guide our team’s development and collaboration processes. Adhering to these policies ensures consistency, quality, and efficient collaboration within the project.
|
||||||
|
|
||||||
|
## Table of Contents
|
||||||
|
|
||||||
|
1. [Overview](#overview)
|
||||||
|
2. [File Descriptions](#file-descriptions)
|
||||||
|
- [CodingStandards.md](#codingstandardsmd)
|
||||||
|
- [CommunicationStandards.md](#communicationstandardsmd)
|
||||||
|
- [DocumentationStandards.md](#documentationstandardsmd)
|
||||||
|
- [FilePathStandards.md](#filepathstandardsmd)
|
||||||
|
- [GitAndGitHubStandards.md](#gitandgithubstandardsmd)
|
||||||
|
3. [Using this Documentation](#using-this-documentation)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
This directory serves as the central reference point for all policies and standards governing our project’s development practices. Each document is purpose-built to address specific facets of our workflow, from coding conventions to GitHub management. Contributors should familiarize themselves with each section to ensure their work aligns with our established standards.
|
||||||
|
|
||||||
|
## File Descriptions
|
||||||
|
|
||||||
|
### 1. CodingStandards.md
|
||||||
|
**Purpose**: Defines the coding standards for our primary language, Python, along with additional guidelines for languages that interact with Python (e.g., C, JSON, Rust).
|
||||||
|
|
||||||
|
**Key Points**:
|
||||||
|
- **Python Coding Standards**: Emphasizes PEP8 adherence, docstrings, naming conventions, and version control with `venv`.
|
||||||
|
- **Interface Language Standards**: Guidance on C extensions, Rust integration, TypeScript, JSON, and SQL standards.
|
||||||
|
- **Virtual Environments**: Explanation of `venv` management, `.gitignore` configurations, and best practices for `requirements.txt`.
|
||||||
|
|
||||||
|
**Useful for**: Any team member involved in writing or reviewing code across languages, especially those needing to understand Python-centric practices.
|
||||||
|
|
||||||
|
### 2. CommunicationStandards.md
|
||||||
|
**Purpose**: Provides guidelines for communication, task assignment, and collaboration methods, ensuring smooth project coordination and prompt issue resolution.
|
||||||
|
|
||||||
|
**Key Points**:
|
||||||
|
- **Communication Channels**: Standards for using GitHub Issues, Pull Requests, and team meetings.
|
||||||
|
- **Collaborative Practices**: Code review protocols, issue assignments, and conflict resolution strategies.
|
||||||
|
- **Labor Distribution**: Suggested systems for assigning and managing tasks effectively within GitHub.
|
||||||
|
|
||||||
|
**Useful for**: Contributors and project managers coordinating workflow, code reviews, and project task assignments.
|
||||||
|
|
||||||
|
### 3. DocumentationStandards.md
|
||||||
|
**Purpose**: Outlines best practices for documenting code, project functionality, and business-related information, maintaining accessible and comprehensive documentation.
|
||||||
|
|
||||||
|
**Key Points**:
|
||||||
|
- **README and Inline Documentation**: Standards for writing and organizing README files for each module, docstrings, and inline comments.
|
||||||
|
- **Documentation File Naming**: Instructions on file naming, Markdown use, and placement of documentation within the directory structure.
|
||||||
|
- **Documentation for Modular Code**: Guidelines on modular documentation, where root-level modules should contain individual `README.md` files.
|
||||||
|
|
||||||
|
**Useful for**: Anyone writing documentation, comments, or README files to support the codebase and clarify business practices.
|
||||||
|
|
||||||
|
### 4. FilePathStandards.md
|
||||||
|
**Purpose**: Establishes naming conventions and directory structures to ensure consistency across the entire codebase.
|
||||||
|
|
||||||
|
**Key Points**:
|
||||||
|
- **Directory Structure**: Suggested layout for primary directories (`src/`, `docs/`, `tests/`, etc.) and subdirectories for functionality-specific code.
|
||||||
|
- **File Naming Conventions**: Rules for lowercase, underscored, and hyphenated naming styles to avoid ambiguity.
|
||||||
|
- **Special Conventions**: Specific guidelines for the `docs/` directory structure, README file formats, and `data` directory usage.
|
||||||
|
|
||||||
|
**Useful for**: Contributors adding or reorganizing files, ensuring all files and directories comply with standard naming and structure guidelines.
|
||||||
|
|
||||||
|
### 5. GitAndGitHubStandards.md
|
||||||
|
**Purpose**: Provides a thorough explanation of Git and GitHub practices, branch naming conventions, and commit message formatting, ensuring effective version control and collaboration.
|
||||||
|
|
||||||
|
**Key Points**:
|
||||||
|
- **Git Overview and Workflows**: Explains the basics of Git, including branch structure, merging practices, and handling merge conflicts.
|
||||||
|
- **Commit Messages**: Detailed formatting for clear and useful commit messages.
|
||||||
|
- **Branch Naming Conventions**: Guidelines on naming branches based on purpose (e.g., `feature/`, `bugfix/`) to keep the repository organized.
|
||||||
|
|
||||||
|
**Useful for**: Contributors managing version control through Git and GitHub, particularly when creating branches or preparing for merges.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Using this Documentation
|
||||||
|
|
||||||
|
- **Navigation**: Each document can be navigated using the Table of Contents above. For users with VimWiki enabled in Vim or Neovim, Markdown links will automatically convert into navigable wiki-style links.
|
||||||
|
- **Before Making Changes**: Always review the relevant standards document before adding or modifying files, writing documentation, or altering code.
|
||||||
|
- **Updating Documentation**: If your code contributions impact an existing policy or standard, consult with the project maintainer to ensure documentation is updated accordingly.
|
||||||
|
|
||||||
|
By following the practices outlined in these files, you’ll help maintain the quality, readability, and organization of our project, benefiting both current contributors and future collaborators.
|
||||||
|
|
||||||
Reference in New Issue
Block a user