You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shardingsphere.apache.org by Sheng Wu <wu...@gmail.com> on 2019/09/13 05:02:55 UTC
[DISCUSS] Set up new work flow for ShardingSphere
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
Re: [DISCUSS] Set up new work flow for ShardingSphere
Posted by Willem Jiang <wi...@gmail.com>.
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 <wu...@gmail.com> 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
Re: [DISCUSS] Set up new work flow for ShardingSphere
Posted by "zhangliang@apache.org" <zh...@apache.org>.
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 <zh...@126.com> 于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 <pa...@apache.org> 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
> > |
> > |
> > panjuan@apache.org
> > Juan Pan(Trista), Apache ShardingSphere
> > |
> > 签名由网易邮箱大师定制
> >
> >
> > On 09/13/2019 13:02，Sheng Wu<wu...@gmail.com> 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
>
>
Re: [DISCUSS] Set up new work flow for ShardingSphere
Posted by zhaojun <zh...@126.com>.
+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 <pa...@apache.org> 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
> |
> |
> panjuan@apache.org
> Juan Pan(Trista), Apache ShardingSphere
> |
> 签名由网易邮箱大师定制
>
>
> On 09/13/2019 13:02，Sheng Wu<wu...@gmail.com> 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
Re:[DISCUSS] Set up new work flow for ShardingSphere
Posted by Juan Pan <pa...@apache.org>.
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
|
|
panjuan@apache.org
Juan Pan(Trista), Apache ShardingSphere
|
签名由网易邮箱大师定制
On 09/13/2019 13:02，Sheng Wu<wu...@gmail.com> 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