Yes, I agree to set up workflow for ShardingSphere. After discussion, I think make a general and clear open source rule and workflow is important. I talk with Craig during ApacheCon, he also suggested that.
ShardingSphere has entered apache incubator about 10 moths, I am glad to see our improvement for the community. After what we understand apache way more and more, we should keep improving and practice apache way better. The changes has already happened for all of the 5 lists above. ------------------ Liang Zhang (John) Apache ShardingSphere & Dubbo zhaojun <[email protected]> 于2019年9月13日周五 下午8:46写道： > +1 > > We should build a work flow that people outside JD can also complete a > core feature. > As initial committer, we should share our knowledge on how to resolve > problems, > Break requirements down into small pieces that can do pull request and > review by others. > > ------------------ > Zhao Jun > Apache Sharding-Sphere & ServiceComb > > > > On Sep 13, 2019, at 2:06 PM, Juan Pan <[email protected]> wrote: > > > > Hi Sheng, > > > > > > Thanks for your suggestions for ShardingSphere community. > > > > > > After scanning your suggestions, some of pains brought up really exist > now, i think. Moreover, sorry, i did. > > > > > > After ShardingSphere entering into incubator, it is growing up quickly, > but its growth of community can not keep the same pace with its features, > for we put more attention on its functions and features. If we want to make > ShardingSphere become better and better, the strength of community is > essential. We should become more open-minded and give more trust and time > to all the contributors and committers. > > > > > > How and why we need to build an active, open and diverse community is > always puzzling me, not just as PPMC of ShardingSphere, but a person who > has interest and enthusiasm of Apache community. I think those items > seriously, and it is time to take a change, i think. > > > > > > I regret not being able to attend ApacheConn, and communicating with > some one of you. :( > > > > > > I also want to listen to others’ voice of setting up a new workflow for > ShardingSphere. > > > > > > Best wishes, > > Trista > > > > > > | | > > Juan Pan > > | > > | > > [email protected] > > Juan Pan(Trista), Apache ShardingSphere > > | > > 签名由网易邮箱大师定制 > > > > > > On 09/13/2019 13:02，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 > >
