CMDA Community Issues

[Greg Reddin <gr...@gmail.com>]

Hi CMDA,

It is my goal for this project to succeed at Apache, but I think there
is a disconnect that needs to be addressed. I want to raise some of
the specific issues that I have seen that need to be addressed and
give some practical tips on how to address them. Please understand
that I don't mean to offend anyone by this message. My goal is to help
you understand what is needed to get on the right path. Please let me
know if any clarity is needed.

First, the project seems to be too dependent on school projects. It
appears that much of the project's work and direction are decided by a
few people who are preparing for the next semester of school. The CMDA
community on the dev list do not have any visibility into these
decisions until after the fact. This may be something that makes the
project incompatible with Apache. If the project revolves around the
agenda of a few people driven by their teaching needs, it is by
definition, not a community led project. For us to succeed at Apache,
the school projects must become ancillary to the core of the project.
CMDA should be able to continue on in its own direction without
dependencies on student work that has specific requirements and
timeframes. I'll offer below some advice on how to incorporate student
projects.

Second, code is not developed in Apache repositories. Instead it is
imported in bulk. For CMDA to be a community-driven project code must
be committed directly to the Apache repo first. If some folks need to
maintain a fork for their own uses elsewhere, including for student
projects, that's fine. But individual commits, not bulk commits need
to be taking place in Apache repos, not external ones.

Third, decisions are not made by the community. They appear to be made
by a few people separate from the dev list and presented here after
the fact. We see meeting minutes where things have been decided and
assignments made. If I want to contribute to the Docker container, how
can I do that? If I want to contribute to improving the HTML front
ends how would I go about that? How can someone from the outside of
your core group help decide what the next step will be and contribute
code? That's the essence of the Apache Way.

Now, here are some specific things I need to see before I can say the
project is making progress in the right direction.

1. Code from school projects should be submitted to Apache by the
author and committed to the Apache repo by a CMDA committer. It can be
submitted through a Jira attachment, GitHub pull request, etc.

2. Discussion regarding school projects should take place on the CMDA dev list.

3. We must see commits of code to the Apache CMDA repository. These
are not imports of large blocks of code worked on for a long time, but
individual changes submitted one at a time directly to the Apache
project. The Apache repo must be the primary source code repository.

4. Make decisions regarding code and project direction on the CMDA dev
list. Offlist face-to-face meetings are ok, but no decisions can be
made, only recommendations. If someone on list offers an alternative
solution to any of those recommendations it must receive equal weight
and the community decides collectively how to proceed.

Discussions regarding project direction, features, releases, who's
working on what, etc. must take place on the CMDA dev list.

Finally, please understand that if the project is not compatible with
the Apache style of development, it's not a failure. It would not be a
bad mark on your "resume'." It would simply mean that the project
relies on some tenets of development that are not driven by the
community. Perhaps it is better for this project to be presented to
the community after work is done, as opposed to allowing the community
broad input as to its direction. If so that's fine. But if you want to
be at Apache that broad input from the community is an absolute
requirement.

Please let me know if any clarification of these points is needed.

Thanks,
Greg

Re: CMDA Community Issues

[Jia Zhang <ji...@west.cmu.edu>]

Dear Greg,

Thanks a lot for your detailed instructions on Apache requirements. Very clear. The CMDA community is going to have meeting and figure out ways to adjust our operations to match Apache requirements.

Best regards,
Jia

> On Jul 6, 2016, at 9:38 AM, Greg Reddin <gr...@gmail.com> wrote:
> 
> Hi CMDA,
> 
> It is my goal for this project to succeed at Apache, but I think there
> is a disconnect that needs to be addressed. I want to raise some of
> the specific issues that I have seen that need to be addressed and
> give some practical tips on how to address them. Please understand
> that I don't mean to offend anyone by this message. My goal is to help
> you understand what is needed to get on the right path. Please let me
> know if any clarity is needed.
> 
> First, the project seems to be too dependent on school projects. It
> appears that much of the project's work and direction are decided by a
> few people who are preparing for the next semester of school. The CMDA
> community on the dev list do not have any visibility into these
> decisions until after the fact. This may be something that makes the
> project incompatible with Apache. If the project revolves around the
> agenda of a few people driven by their teaching needs, it is by
> definition, not a community led project. For us to succeed at Apache,
> the school projects must become ancillary to the core of the project.
> CMDA should be able to continue on in its own direction without
> dependencies on student work that has specific requirements and
> timeframes. I'll offer below some advice on how to incorporate student
> projects.
> 
> Second, code is not developed in Apache repositories. Instead it is
> imported in bulk. For CMDA to be a community-driven project code must
> be committed directly to the Apache repo first. If some folks need to
> maintain a fork for their own uses elsewhere, including for student
> projects, that's fine. But individual commits, not bulk commits need
> to be taking place in Apache repos, not external ones.
> 
> Third, decisions are not made by the community. They appear to be made
> by a few people separate from the dev list and presented here after
> the fact. We see meeting minutes where things have been decided and
> assignments made. If I want to contribute to the Docker container, how
> can I do that? If I want to contribute to improving the HTML front
> ends how would I go about that? How can someone from the outside of
> your core group help decide what the next step will be and contribute
> code? That's the essence of the Apache Way.
> 
> Now, here are some specific things I need to see before I can say the
> project is making progress in the right direction.
> 
> 1. Code from school projects should be submitted to Apache by the
> author and committed to the Apache repo by a CMDA committer. It can be
> submitted through a Jira attachment, GitHub pull request, etc.
> 
> 2. Discussion regarding school projects should take place on the CMDA dev list.
> 
> 3. We must see commits of code to the Apache CMDA repository. These
> are not imports of large blocks of code worked on for a long time, but
> individual changes submitted one at a time directly to the Apache
> project. The Apache repo must be the primary source code repository.
> 
> 4. Make decisions regarding code and project direction on the CMDA dev
> list. Offlist face-to-face meetings are ok, but no decisions can be
> made, only recommendations. If someone on list offers an alternative
> solution to any of those recommendations it must receive equal weight
> and the community decides collectively how to proceed.
> 
> Discussions regarding project direction, features, releases, who's
> working on what, etc. must take place on the CMDA dev list.
> 
> Finally, please understand that if the project is not compatible with
> the Apache style of development, it's not a failure. It would not be a
> bad mark on your "resume'." It would simply mean that the project
> relies on some tenets of development that are not driven by the
> community. Perhaps it is better for this project to be presented to
> the community after work is done, as opposed to allowing the community
> broad input as to its direction. If so that's fine. But if you want to
> be at Apache that broad input from the community is an absolute
> requirement.
> 
> Please let me know if any clarification of these points is needed.
> 
> Thanks,
> Greg

Re: CMDA Community Issues

["Mattmann, Chris A (3980)" <ch...@jpl.nasa.gov>]

This is great advice I recommend folks read it carefully.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattmann@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Director, Information Retrieval and Data Science Group (IRDS)
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
WWW: http://irds.usc.edu/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++










On 7/6/16, 9:38 AM, "Greg Reddin" <gr...@gmail.com> wrote:

>Hi CMDA,
>
>It is my goal for this project to succeed at Apache, but I think there
>is a disconnect that needs to be addressed. I want to raise some of
>the specific issues that I have seen that need to be addressed and
>give some practical tips on how to address them. Please understand
>that I don't mean to offend anyone by this message. My goal is to help
>you understand what is needed to get on the right path. Please let me
>know if any clarity is needed.
>
>First, the project seems to be too dependent on school projects. It
>appears that much of the project's work and direction are decided by a
>few people who are preparing for the next semester of school. The CMDA
>community on the dev list do not have any visibility into these
>decisions until after the fact. This may be something that makes the
>project incompatible with Apache. If the project revolves around the
>agenda of a few people driven by their teaching needs, it is by
>definition, not a community led project. For us to succeed at Apache,
>the school projects must become ancillary to the core of the project.
>CMDA should be able to continue on in its own direction without
>dependencies on student work that has specific requirements and
>timeframes. I'll offer below some advice on how to incorporate student
>projects.
>
>Second, code is not developed in Apache repositories. Instead it is
>imported in bulk. For CMDA to be a community-driven project code must
>be committed directly to the Apache repo first. If some folks need to
>maintain a fork for their own uses elsewhere, including for student
>projects, that's fine. But individual commits, not bulk commits need
>to be taking place in Apache repos, not external ones.
>
>Third, decisions are not made by the community. They appear to be made
>by a few people separate from the dev list and presented here after
>the fact. We see meeting minutes where things have been decided and
>assignments made. If I want to contribute to the Docker container, how
>can I do that? If I want to contribute to improving the HTML front
>ends how would I go about that? How can someone from the outside of
>your core group help decide what the next step will be and contribute
>code? That's the essence of the Apache Way.
>
>Now, here are some specific things I need to see before I can say the
>project is making progress in the right direction.
>
>1. Code from school projects should be submitted to Apache by the
>author and committed to the Apache repo by a CMDA committer. It can be
>submitted through a Jira attachment, GitHub pull request, etc.
>
>2. Discussion regarding school projects should take place on the CMDA dev list.
>
>3. We must see commits of code to the Apache CMDA repository. These
>are not imports of large blocks of code worked on for a long time, but
>individual changes submitted one at a time directly to the Apache
>project. The Apache repo must be the primary source code repository.
>
>4. Make decisions regarding code and project direction on the CMDA dev
>list. Offlist face-to-face meetings are ok, but no decisions can be
>made, only recommendations. If someone on list offers an alternative
>solution to any of those recommendations it must receive equal weight
>and the community decides collectively how to proceed.
>
>Discussions regarding project direction, features, releases, who's
>working on what, etc. must take place on the CMDA dev list.
>
>Finally, please understand that if the project is not compatible with
>the Apache style of development, it's not a failure. It would not be a
>bad mark on your "resume'." It would simply mean that the project
>relies on some tenets of development that are not driven by the
>community. Perhaps it is better for this project to be presented to
>the community after work is done, as opposed to allowing the community
>broad input as to its direction. If so that's fine. But if you want to
>be at Apache that broad input from the community is an absolute
>requirement.
>
>Please let me know if any clarification of these points is needed.
>
>Thanks,
>Greg

Re: CMDA Community Issues

[Jia Zhang <ji...@sv.cmu.edu>]

Dear Michael:

Thanks for the detailed advice. We will adopt a JIRA ticket way for student
contributors then.

Best regards,
Jia

On Mon, Jul 11, 2016 at 12:26 PM, Michael Joyce <jo...@apache.org> wrote:

> I think the intention regarding student code integration is coming from the
> angle that a student making a contribution to the project for the first
> time wouldn't be a PMC/Committer. As such they would put up their
> contributions in a pull request and reference a JIRA ticket that is
> tracking the work (or w/e the project uses here) and a committer on the
> project could then review and integrate the code. Their code should not be
> bulk integrated by someone else on the project without any tracking of the
> individuals efforts.
>
> I would strongly recommend against setting up some specific groups of
> people as being a gateway for code integration.
>
> +1 to the OP as well. Lots of great points that need to be very seriously
> reviewed by the project
>
> -- Jimmy
>
> On Thu, Jul 7, 2016 at 3:48 PM, Jia Zhang <ji...@sv.cmu.edu> wrote:
>
> > Dear Greg:
> >
> > Thanks a lot for your detailed guidance on Apache style.
> >
> > I have a quick question...you mentioned that "Code from school projects
> > should be submitted to Apache by the author and committed to the Apache
> > repo by a CMDA committer." Do you mean that we should identify a couple
> of
> > CMDA committers to be gateway (QA controller), who will take student
> > submission, check them, and then check into Apache CMDA repo?
> >
> > Thanks a lot.
> >
> > Best regards,
> > Jia
> >
> >
> >
> > On Wed, Jul 6, 2016 at 9:38 AM, Greg Reddin <gr...@gmail.com> wrote:
> >
> > > Hi CMDA,
> > >
> > > It is my goal for this project to succeed at Apache, but I think there
> > > is a disconnect that needs to be addressed. I want to raise some of
> > > the specific issues that I have seen that need to be addressed and
> > > give some practical tips on how to address them. Please understand
> > > that I don't mean to offend anyone by this message. My goal is to help
> > > you understand what is needed to get on the right path. Please let me
> > > know if any clarity is needed.
> > >
> > > First, the project seems to be too dependent on school projects. It
> > > appears that much of the project's work and direction are decided by a
> > > few people who are preparing for the next semester of school. The CMDA
> > > community on the dev list do not have any visibility into these
> > > decisions until after the fact. This may be something that makes the
> > > project incompatible with Apache. If the project revolves around the
> > > agenda of a few people driven by their teaching needs, it is by
> > > definition, not a community led project. For us to succeed at Apache,
> > > the school projects must become ancillary to the core of the project.
> > > CMDA should be able to continue on in its own direction without
> > > dependencies on student work that has specific requirements and
> > > timeframes. I'll offer below some advice on how to incorporate student
> > > projects.
> > >
> > > Second, code is not developed in Apache repositories. Instead it is
> > > imported in bulk. For CMDA to be a community-driven project code must
> > > be committed directly to the Apache repo first. If some folks need to
> > > maintain a fork for their own uses elsewhere, including for student
> > > projects, that's fine. But individual commits, not bulk commits need
> > > to be taking place in Apache repos, not external ones.
> > >
> > > Third, decisions are not made by the community. They appear to be made
> > > by a few people separate from the dev list and presented here after
> > > the fact. We see meeting minutes where things have been decided and
> > > assignments made. If I want to contribute to the Docker container, how
> > > can I do that? If I want to contribute to improving the HTML front
> > > ends how would I go about that? How can someone from the outside of
> > > your core group help decide what the next step will be and contribute
> > > code? That's the essence of the Apache Way.
> > >
> > > Now, here are some specific things I need to see before I can say the
> > > project is making progress in the right direction.
> > >
> > > 1. Code from school projects should be submitted to Apache by the
> > > author and committed to the Apache repo by a CMDA committer. It can be
> > > submitted through a Jira attachment, GitHub pull request, etc.
> > >
> > > 2. Discussion regarding school projects should take place on the CMDA
> dev
> > > list.
> > >
> > > 3. We must see commits of code to the Apache CMDA repository. These
> > > are not imports of large blocks of code worked on for a long time, but
> > > individual changes submitted one at a time directly to the Apache
> > > project. The Apache repo must be the primary source code repository.
> > >
> > > 4. Make decisions regarding code and project direction on the CMDA dev
> > > list. Offlist face-to-face meetings are ok, but no decisions can be
> > > made, only recommendations. If someone on list offers an alternative
> > > solution to any of those recommendations it must receive equal weight
> > > and the community decides collectively how to proceed.
> > >
> > > Discussions regarding project direction, features, releases, who's
> > > working on what, etc. must take place on the CMDA dev list.
> > >
> > > Finally, please understand that if the project is not compatible with
> > > the Apache style of development, it's not a failure. It would not be a
> > > bad mark on your "resume'." It would simply mean that the project
> > > relies on some tenets of development that are not driven by the
> > > community. Perhaps it is better for this project to be presented to
> > > the community after work is done, as opposed to allowing the community
> > > broad input as to its direction. If so that's fine. But if you want to
> > > be at Apache that broad input from the community is an absolute
> > > requirement.
> > >
> > > Please let me know if any clarification of these points is needed.
> > >
> > > Thanks,
> > > Greg
> > >
> >
>

Re: CMDA Community Issues

[Michael Joyce <jo...@apache.org>]

I think the intention regarding student code integration is coming from the
angle that a student making a contribution to the project for the first
time wouldn't be a PMC/Committer. As such they would put up their
contributions in a pull request and reference a JIRA ticket that is
tracking the work (or w/e the project uses here) and a committer on the
project could then review and integrate the code. Their code should not be
bulk integrated by someone else on the project without any tracking of the
individuals efforts.

I would strongly recommend against setting up some specific groups of
people as being a gateway for code integration.

+1 to the OP as well. Lots of great points that need to be very seriously
reviewed by the project

-- Jimmy

On Thu, Jul 7, 2016 at 3:48 PM, Jia Zhang <ji...@sv.cmu.edu> wrote:

> Dear Greg:
>
> Thanks a lot for your detailed guidance on Apache style.
>
> I have a quick question...you mentioned that "Code from school projects
> should be submitted to Apache by the author and committed to the Apache
> repo by a CMDA committer." Do you mean that we should identify a couple of
> CMDA committers to be gateway (QA controller), who will take student
> submission, check them, and then check into Apache CMDA repo?
>
> Thanks a lot.
>
> Best regards,
> Jia
>
>
>
> On Wed, Jul 6, 2016 at 9:38 AM, Greg Reddin <gr...@gmail.com> wrote:
>
> > Hi CMDA,
> >
> > It is my goal for this project to succeed at Apache, but I think there
> > is a disconnect that needs to be addressed. I want to raise some of
> > the specific issues that I have seen that need to be addressed and
> > give some practical tips on how to address them. Please understand
> > that I don't mean to offend anyone by this message. My goal is to help
> > you understand what is needed to get on the right path. Please let me
> > know if any clarity is needed.
> >
> > First, the project seems to be too dependent on school projects. It
> > appears that much of the project's work and direction are decided by a
> > few people who are preparing for the next semester of school. The CMDA
> > community on the dev list do not have any visibility into these
> > decisions until after the fact. This may be something that makes the
> > project incompatible with Apache. If the project revolves around the
> > agenda of a few people driven by their teaching needs, it is by
> > definition, not a community led project. For us to succeed at Apache,
> > the school projects must become ancillary to the core of the project.
> > CMDA should be able to continue on in its own direction without
> > dependencies on student work that has specific requirements and
> > timeframes. I'll offer below some advice on how to incorporate student
> > projects.
> >
> > Second, code is not developed in Apache repositories. Instead it is
> > imported in bulk. For CMDA to be a community-driven project code must
> > be committed directly to the Apache repo first. If some folks need to
> > maintain a fork for their own uses elsewhere, including for student
> > projects, that's fine. But individual commits, not bulk commits need
> > to be taking place in Apache repos, not external ones.
> >
> > Third, decisions are not made by the community. They appear to be made
> > by a few people separate from the dev list and presented here after
> > the fact. We see meeting minutes where things have been decided and
> > assignments made. If I want to contribute to the Docker container, how
> > can I do that? If I want to contribute to improving the HTML front
> > ends how would I go about that? How can someone from the outside of
> > your core group help decide what the next step will be and contribute
> > code? That's the essence of the Apache Way.
> >
> > Now, here are some specific things I need to see before I can say the
> > project is making progress in the right direction.
> >
> > 1. Code from school projects should be submitted to Apache by the
> > author and committed to the Apache repo by a CMDA committer. It can be
> > submitted through a Jira attachment, GitHub pull request, etc.
> >
> > 2. Discussion regarding school projects should take place on the CMDA dev
> > list.
> >
> > 3. We must see commits of code to the Apache CMDA repository. These
> > are not imports of large blocks of code worked on for a long time, but
> > individual changes submitted one at a time directly to the Apache
> > project. The Apache repo must be the primary source code repository.
> >
> > 4. Make decisions regarding code and project direction on the CMDA dev
> > list. Offlist face-to-face meetings are ok, but no decisions can be
> > made, only recommendations. If someone on list offers an alternative
> > solution to any of those recommendations it must receive equal weight
> > and the community decides collectively how to proceed.
> >
> > Discussions regarding project direction, features, releases, who's
> > working on what, etc. must take place on the CMDA dev list.
> >
> > Finally, please understand that if the project is not compatible with
> > the Apache style of development, it's not a failure. It would not be a
> > bad mark on your "resume'." It would simply mean that the project
> > relies on some tenets of development that are not driven by the
> > community. Perhaps it is better for this project to be presented to
> > the community after work is done, as opposed to allowing the community
> > broad input as to its direction. If so that's fine. But if you want to
> > be at Apache that broad input from the community is an absolute
> > requirement.
> >
> > Please let me know if any clarification of these points is needed.
> >
> > Thanks,
> > Greg
> >
>

Re: CMDA Community Issues

[Jia Zhang <ji...@sv.cmu.edu>]

Dear Greg:

Thanks a lot for your detailed guidance on Apache style.

I have a quick question...you mentioned that "Code from school projects
should be submitted to Apache by the author and committed to the Apache
repo by a CMDA committer." Do you mean that we should identify a couple of
CMDA committers to be gateway (QA controller), who will take student
submission, check them, and then check into Apache CMDA repo?

Thanks a lot.

Best regards,
Jia



On Wed, Jul 6, 2016 at 9:38 AM, Greg Reddin <gr...@gmail.com> wrote:

> Hi CMDA,
>
> It is my goal for this project to succeed at Apache, but I think there
> is a disconnect that needs to be addressed. I want to raise some of
> the specific issues that I have seen that need to be addressed and
> give some practical tips on how to address them. Please understand
> that I don't mean to offend anyone by this message. My goal is to help
> you understand what is needed to get on the right path. Please let me
> know if any clarity is needed.
>
> First, the project seems to be too dependent on school projects. It
> appears that much of the project's work and direction are decided by a
> few people who are preparing for the next semester of school. The CMDA
> community on the dev list do not have any visibility into these
> decisions until after the fact. This may be something that makes the
> project incompatible with Apache. If the project revolves around the
> agenda of a few people driven by their teaching needs, it is by
> definition, not a community led project. For us to succeed at Apache,
> the school projects must become ancillary to the core of the project.
> CMDA should be able to continue on in its own direction without
> dependencies on student work that has specific requirements and
> timeframes. I'll offer below some advice on how to incorporate student
> projects.
>
> Second, code is not developed in Apache repositories. Instead it is
> imported in bulk. For CMDA to be a community-driven project code must
> be committed directly to the Apache repo first. If some folks need to
> maintain a fork for their own uses elsewhere, including for student
> projects, that's fine. But individual commits, not bulk commits need
> to be taking place in Apache repos, not external ones.
>
> Third, decisions are not made by the community. They appear to be made
> by a few people separate from the dev list and presented here after
> the fact. We see meeting minutes where things have been decided and
> assignments made. If I want to contribute to the Docker container, how
> can I do that? If I want to contribute to improving the HTML front
> ends how would I go about that? How can someone from the outside of
> your core group help decide what the next step will be and contribute
> code? That's the essence of the Apache Way.
>
> Now, here are some specific things I need to see before I can say the
> project is making progress in the right direction.
>
> 1. Code from school projects should be submitted to Apache by the
> author and committed to the Apache repo by a CMDA committer. It can be
> submitted through a Jira attachment, GitHub pull request, etc.
>
> 2. Discussion regarding school projects should take place on the CMDA dev
> list.
>
> 3. We must see commits of code to the Apache CMDA repository. These
> are not imports of large blocks of code worked on for a long time, but
> individual changes submitted one at a time directly to the Apache
> project. The Apache repo must be the primary source code repository.
>
> 4. Make decisions regarding code and project direction on the CMDA dev
> list. Offlist face-to-face meetings are ok, but no decisions can be
> made, only recommendations. If someone on list offers an alternative
> solution to any of those recommendations it must receive equal weight
> and the community decides collectively how to proceed.
>
> Discussions regarding project direction, features, releases, who's
> working on what, etc. must take place on the CMDA dev list.
>
> Finally, please understand that if the project is not compatible with
> the Apache style of development, it's not a failure. It would not be a
> bad mark on your "resume'." It would simply mean that the project
> relies on some tenets of development that are not driven by the
> community. Perhaps it is better for this project to be presented to
> the community after work is done, as opposed to allowing the community
> broad input as to its direction. If so that's fine. But if you want to
> be at Apache that broad input from the community is an absolute
> requirement.
>
> Please let me know if any clarification of these points is needed.
>
> Thanks,
> Greg
>