It's easy to make a offline discussion if you are setting together, but it's impossible for the outside contributor to know the design details without having a face 2 face talk with the core development team. Open Source means openness and cooperation, we should avoid internal discussions to keep the community updated with latest roadmap. I agree with wushen and growing the community should be the high priority for the podling projects.
Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Fri, Sep 13, 2019 at 1:03 PM Sheng Wu <[email protected]> wrote: > > Hi ShardingSphere > > With the one whole week at ApacheCon NA, I finally got time to take with > Liang Zhang for a long time(several days) about the community and workflow > of ShardingSphere community. > First of all, due to our discussion for lower the bar, we have more > committers and will have more PPMC. This is a good sign for our community > growth. > But, I also hope we could do much better than now. > > It is about the open source workflow, I am aware of that, today most > features of ShardingSphere still come from the initial committer team > inside JD.com. > This is not a bad thing, but I want to involve more contributors in, engage > with them, encourage them, and make them feel being a part of the core > team, rather than following the contribution guidelines, or do outside > supports. > > (For the core team, I mean the ShardingSphere could trust the workflow, a > contributor out of jd.com, could do a core feature change with clear path > and accepted by the PPMC) > > For making the community more open, I suggest > 1. Make sure all changes must through pull request, no commit(especially > for initial committer) lands on master/dev branch directly. > 2. All pull request must be reviewed by at least one committer, and get > approvement. Also don't get `request change` from the committer > 3. Pull request should be goal clear, small enough to be reviewed. Today, > too many huge PR with over 40+ files change, even 1k+ lines. Those are > impossible to be reviewed. > 4. Pull request should be `squash and merge`, rather than today, the commit > log is not controlled, it becomes unreadable and unreasonable. > 5. All pull request must have a clear description of why do this change and > how. If necessary, provide the design document. > > ShardingSphere hopes to move fast, it totally makes sense to me, but all > actions need to follow open source culture. Being open, understandable and > trackable. > Not just for codes, but for Issue, Pull Request, Design, Proposal, Review. > > The core goal of all these suggestions is, make new contributors, existing > contributors, and committer out of jd.com team, understand what is > happening in the community. > > One of the most talking about issue is, people are keeping waiting for core > team to fix or do a new release, then only use it than contributing to the > upstream. > The root cause is the path of development is unclear from an individual out > of the team. > > Please feedback about what do you feel about this, and do we want to do > this. > > This is my most wanted change to ShardingSphere before the graduation, in > order to make it possible to become an active, open, diversity community. > You don't need to agree to me, this is just my feeling. I am away from code > contributions to ShardingSphere for a long time, even before joining the > incubator and open source happens. > So, maybe there is some pain I am not aware of, please bring it up, and > talk. > > > Sheng Wu 吴晟 > > Apache SkyWalking > Apache Incubator > Apache ShardingSphere, ECharts, DolphinScheduler podlings > Zipkin > Twitter, wusheng1108
