-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensuring the development of CM-based automation for MLPerf complies with MLCommons bylaws #641
Comments
@gfursin Can you please point to the section in the MLCommons bylaws which is violated by the creation of a "fork"? Fork by itself does an acknowledgement and endorsement and MLCommons bylaws clearly states the below.
Meanwhile when two people jointly develop a project it is unfair to write a white paper under one person name and publicize it. If anyone does this, no sane person will ever collaborate with him/her. No law matters here. "I donated CK, CM and CM4MLOps to MLCommons " is mentioned here - AFAIK and what the github history shows - CM and CM4MLOps development started within MLCommons and from the start I was a part. But I don't want to argue over the ownership of an open source project - I'm just saying my reasons for not collaborating on such personal projects. Also I'm no longer using this repository and thanks for removing my name as the maintainer here. You can fix and maintain this repository as you prefer. If you feel we are violating any laws in repositories we maintain please point to the exact violation. Otherwise we'll see what MLCommons has to say. |
@arjunsuresh . What you are stating is false and easy to check via history of commits (in the original repository and not in this one with truncated history) - checking that with MLCommons ... |
Sorry - what exactly is false? This file is created by you only and you can see the development history in case you have forgotten. |
We will discuss all of this with MLCommons. In the meantime, I have restored the deleted files and the core functionality necessary for other projects and will consult with MLCommons to decide what to do with this repository, branches and forks. |
Sure. We are no longer using this repository as we are not working on any When managing an open-source repository, ensuring that forks don't negatively impact the original project involves a combination of proper licensing, governance, and clear communication. Here are steps to manage this effectively: 1. Use an Open Source LicenseWhy:A well-defined license ensures users know their rights and obligations when forking your repository. How:
Impact:A proper license gives legal clarity, ensuring forks align with your project’s values. 2. Set Contributor GuidelinesWhy:Forks often occur because contributors find it hard to work within the main repository. How:
Impact:This reduces forks caused by communication gaps and encourages collaboration. 3. Build a Strong Governance ModelWhy:A clear governance structure helps maintain control over the direction of the project. How:
Impact:A strong governance model ensures contributors trust the process, reducing unnecessary forks. 4. Maintain High-Quality DocumentationWhy:Forks often arise due to unclear goals, vision, or usage instructions. How:
Impact:Good documentation keeps contributors aligned with your vision, reducing fragmented forks. 5. Monitor and Engage With ForksWhy:Understanding why forks exist helps you address potential issues proactively. How:
Impact:Proactive engagement prevents forks from diverging in ways that harm the ecosystem. 6. Trademark or Branding ControlsWhy:Prevent unauthorized use of your project's name or brand in forks. How:
Impact:This ensures forks don’t confuse users or dilute the reputation of your project. 7. Encourage Upstream ContributionsWhy:Fork maintainers might bypass your repository if contributing upstream is difficult. How:
Impact:Forks are more likely to contribute improvements back to the original project. 8. Automate Repository MaintenanceWhy:A well-maintained repository is less likely to be forked unnecessarily. How:
Impact:A well-maintained repository signals professionalism, attracting contributors instead of forkers. 9. Be Open to CollaborationWhy:Community engagement reduces competition between forks and the main project. How:
Impact:Collaborative practices strengthen the main repository and minimize fragmentation. 10. Mitigate Harmful ForksWhy:Sometimes, forks can misrepresent or misuse your work. How:
Impact:This protects your project’s integrity and user trust. SummaryTo ensure forks don't negatively impact your open-source repository:
By fostering a welcoming and organized ecosystem, forks are more likely to enhance rather than harm your project. Let me know if you’d like examples for any specific step! |
Discussing that with MLCommons ... |
My assessments have been confirmed, along with a few additional actions:
|
Several recent changes from last week disrupted my Collective Mind approach of reusing CM automations and artifacts, rather than duplicating or remixing them across different repositories and forks. Consequently, this also impacted several ongoing projects involving various MLCommons members. While addressing these issues with MLCommons, I outlined a set of tasks to resolve them and ensure the continuation of collaborative development for MLPerf automations.
mlperf-inference
andmain
branches of cm4mlops that were removed from the parentmlcommons/ck project
without any discussion and explanation.main
branch instead ofmlperf-inference
and checkouts in the PYPI package to be utilized in other MLCommons repositories. See herepip install cmind
andcm pull repo {url} {branch|checkout}
for greater transparency.The text was updated successfully, but these errors were encountered: