Comments (4)
@WanzenBug @alexzhc @JoelColledge @rck checking in here on the status of this.
from piraeus.
- Project needs to adopt the CNCF code of conduct. The governance file states it is aligned with the CNCF code of conduct however the CoC in the repository is the contributor covenant. Currently, TAG Contributor Strategy recommends projects link directly to the CNCF CoC within their own CoC file so they inherit any changes made in the future.
Addressed with 99a926d
- While there are new contributors to the project, it does not appear to be achieving the anticipated velocity to make substantial progress towards the stated goals and towards incubation.
Thank you for pointing this out. Our expectation with making this a CNCF (sandbox) project is to increase the velocity.
- While the project's README indicated active discussions take place in Slack, a quick review of Piraeus slack shows very little discussion on going beyond periodic requests for assistance in the default channel (about once a week). This is not indicative of a growing community.
Thank you for pointing this out. That is a consequence of the README being outdated. Addressed that with d77d8cf
- The project does not appear to hold meetings to engage in synchronous discussions with contributors, adopters, community members, perform project planning, or any other content. If meetings or discussions are happening in other channels, or platforms, the project must update its documentation to reflect these discoverable and public communication mediums.
Piraeus Datastore is just a glue component between LINSTOR and Kubernetes. People interested in Piraeus Datastore are also interested in LINSTOR and DRBD. LINBIT organizes about 4 community meetings every Year.
In these meetings we regularly have updates about the Pireaus Operator and a synchronous live discussion in a Zoom meeting that is also live streamed via YouTube.
Addressed with d77d8cf
- The project does not appear to engage in any long term planning.
Piraeus Datastore’s long-term plan is to stay current with Kubernetes, LINSTOR, and DRBD developments. I think that is obvious for people looking at it from a technical perspective.
- While development is ongoing, there does not appear to be additional planning towards future releases, no open issues tracking progress or discussions on outstanding areas of improvement, etc. It does not appear tags or milestones are used.
Frequently, Piraeus Datastore’s releases are triggered by LINSTOR releases. I think that is obvious for people looking at it from a technical perspective.
- issues with the project have been open for an extensive period of time with discussions, if they occurred, remaining unresolved.
We like to keep issues open until the underlying issues are resolved or the original author marks the issue as resolved. Oftentimes, this means the issue stays open after initial activity: we try to resolve all reported issues, but we sometimes have a hard time pinpointing the reported issues. In that case, we are dependent on the creator to provide enough information.
Unlike many Kubernetes-related projects, we do not deploy a bot that automatically closes issues after a set period of inactivity. If that is desired, we can set it up.
PS: We love creating great software, but we need help with foundation bureaucracy.
from piraeus.
@Philipp-Reisner Thank you for taking the time to respond and thank you for quickly addressing those recommendations.
Our expectation with making this a CNCF (sandbox) project is to increase the velocity.
This is a reasonable, Sandbox projects are expected to experiment, innovate, and mature towards incubation. However projects are expected to take steps towards incubation, build a sustainable community of contributors and maintainers, and continue to mature the technology alongside their development practices. For some projects, that velocity may be slower due to dependencies or alignment with other projects - this is fine. We want to ensure that our sandbox projects are set up for success and heading in the right direction, thus our periodic check-ins (such as what spawned this Issue).
Piraeus Datastore’s long-term plan is to stay current with Kubernetes, LINSTOR, and DRBD developments. I think that is obvious for people looking at it from a technical perspective.
I genuinely believe every project in the CNCF is intending to stay current with developments in the projects they are dependent upon or interoperate with. The TOC leverages long-term planning as an indicator of evolving project maturity.
In some cases, potential contributors look at project planning to understand if a particular feature or proposal is already planned to be worked, underway, or delayed until a future release. Visibility and transparency into where the project is headed and the open work before them is a good mechanism to attract potential contributors and adopters.
Frequently, Piraeus Datastore’s releases are triggered by LINSTOR releases. I think that is obvious for people looking at it from a technical perspective.
I would recommend adding additional documentation describing the release process for the project so newly come contributors or interested community members can learn about the process and support the maintainers in conducting releases for the project. Kubernetes SIG-Release has a lot of good information for the K8s project does this, it is a heavy for a project like Piraeus however there may be good information for the project to use.
We like to keep issues open until the underlying issues are resolved or the original author marks the issue as resolved. Oftentimes, this means the issue stays open after initial activity: we try to resolve all reported issues, but we sometimes have a hard time pinpointing the reported issues. In that case, we are dependent on the creator to provide enough information.
Makes complete sense, does Piraeus plan to work on all open issues or are some slated for work after certain LINSTOR releases make a feature set or capability available? Its these kinds of planning and engagement activities we look for as indicators of maturity towards incubation. I would recommend adding some clarity to the contributor guide around this to set expectations with individuals submitting issues and PRs (there is a lot of good content in the contributing guide but additional clarity in how the project manages issues and PRs for planning releases is always beneficial).
Unlike many Kubernetes-related projects, we do not deploy a bot that automatically closes issues after a set period of inactivity. If that is desired, we can set it up.
That is up to the project to determine. If you are facing significant issue sprawl and there are known issues that aren't going to be worked, an inactivity bot can take some of the burden off maintainers in closing them, particularly if the submitter is no longer responsive. It just depends on how the project chooses to perform and subsequently document their issue and PR management activities.
PS: We love creating great software, but we need help with foundation bureaucracy.
Fantastic Piraeus love making great software! Amazing cloud native projects have wonderful documentation to go with their great software, both for their current and potential contributors looking to get more involved in the project, as well as for adopters and their organizations looking to understand more about the project, its processes, how it functions, etc. This can support adopters in making informed decisions about the project before committing to a cycle of development, integration and testing, and finally production deployment.
Given your request for assistance in understanding the criteria and expectations for projects in the CNCF, I would recommend reaching out to TAG Storage and participating in one of their meetings as well as reaching out to TAG Contributor Strategy to talk through some of potential discoverability and visibility recommendation which remove ambiguity from the project documentation and processes. CC TAG Storage Chairs: @chira001 , @raffaelespazzoli , @xing-yang & TAG CS Chairs: @jberkus , @CathPag , @geekygirldawn
Regarding the obvious nature of discerning project activity, direction, and planning:
Although these project areas may be obvious to maintainers, it may not be to individuals who are not involved in the day-to-day functions and operations of the project, individuals like users or other engineers looking to contribute - particularly those individuals interested in contributing to a project but are hampered from doing so by the lack of specificity or explicitness in their documentation on how to engage.
I didn't see you listed as a maintainer for the project @Philipp-Reisner, if this is a role you have with the project would you also ensure the MAINTAINERS.md file is up-to-date based on the project's governance?
from piraeus.
Hi @Philipp-Reisner, let us know if you want to come to one of TAG Storage meetings and discuss about Piraeus.
cc @chira001 @raffaelespazzoli
from piraeus.
Related Issues (20)
- piraeus-server,docker: Makefile only builds with bash
- Problems with Ubuntu 22.04 and drbd9-jammy HOT 1
- Unable to find way to reduce placement count HOT 2
- drbd9-focal compilation doesn't work on Ubuntu 20.04 5.15.0-43-generic HOT 1
- Got 401 while creating LinstorCluster: piraeusdatastore/drbd9-bullseye not found in quay.io HOT 1
- ERROR: failed to push quay.io/piraeusdatastore/drbd9-flatcar:v9.1.14: unexpected status: 401 UNAUTHORIZE HOT 1
- CNCF TOC annual review due HOT 2
- Two questions about drbd containerized installation solution HOT 1
- Losing quorum as soon as a node goes down HOT 4
- GitHub repository does not link to the project website url HOT 1
- If pvc goes to diskless (node without local storage) pvc goes into error state
- When several PVCs are created simultaneously, linstor-satelite returns ChildProcessTimeoutException HOT 2
- modinfo 8.4.10 vs. kernel-loader 9.0.27 HOT 4
- Enable DCO per CNCF IP Policy HOT 1
- snapshot stucks and PVC turns readOnlny HOT 5
- Piraeus supports for arm64 HOT 4
- Build multi-arch images HOT 19
- Update from piraeus-server 1.11.1 to 1.12.3 failed with Database initialization error HOT 2
- Add reference in README that you're a CNCF sandbox project
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from piraeus.