Re: Suggestions on how to increase community involvement on Apache MXNet incubating?

[sandeep krishnamurthy]

As mentioned by others, it is very important for the community to know what
is happening, roadmap, low hanging bug fix or feature development.
Along with that, it is hard and time-consuming to get a basic high-level
understanding of various components, architecture and packages of MXNet.

My 2 cent suggestion - Most scalable and useful way of achieving above
objective would be a "set of video lectures on Youtube". We can have couple
of videos to cover topics such as - Introduction to MXNet Architecture and
components, Setting up MXNet on Mac with CLion or PyCharm for Python, Code
walkthrough with usecase - For example: Operator end to end debug trace
walk through.

These videos can be used as resources for developers to play, follow and
get things up and running.

Videos are not a replacement for presence in university lectures,
presentations at conferences. However, videos can be scalable way of
achieving the purpose of getting many people to setup and start seeing code
of MXNet.

Suggestions?

Thanks,
Sandeep

On Thu, Jan 4, 2018 at 10:59 AM, Tianqi Chen 
wrote:

> I think the main point being raised is an easy way to know what is
> happening and proposals.
>
> Github has quite a lot of nice features with respect to this:
>
>  - Issues make perfect sense in terms of discussing a single-point of
> feature/bug and get feedback from anyone who can comment, additionally
> being linked to pull request.
>  - Issues are less useful for long-term roadmaps and discussions, there is
> a feature called project(which is like trello) can be used for such things.
>
> One problem we had in before is that roadmap issues get down the list
> quickly and get deprecated by time without being closed. Aggressively close
> issues and link them from a place that never sink, like project or wiki
> might solve this issue.
>
>
> Additionally, the dev mail list seems to serve a purpose to get to
> developers, which can contain
> - The discussion of major design points, before they actually being landed
> on road-map
> - general questions to raise people's attention to the certain issue being
> progressed
>
> Tianqi
>
> On Thu, Jan 4, 2018 at 10:08 AM, Marco de Abreu <
> marco.g.ab...@googlemail.com> wrote:
>
> > Hello Markus,
> >
> > first of all, very good points!
> >
> > Regarding (1): In my opinion, we should always have some time of chat as
> > this is the most convenient way for users and contributors to ask a quick
> > question. I agree that proper discussions should be held on dev@, but
> > sometimes a quick discussion in a chat is way more effective than writing
> > dozens of emails - also, there might be some people who don't want to
> write
> > an email to a mailing list just to ask a question that can be answered
> > within 10 seconds. So instead I'd propose that we agree on one chat
> > platforms for informal discussions and requests and that everything else
> > gets put on dev@.
> >
> > -Marco
> >
> > On Thu, Jan 4, 2018 at 6:51 PM, Markus Weimer  wrote:
> >
> > > I really like most of what has been said, and the below might be a bit
> > of a
> > > repeat, but through a different lens.
> > >
> > > One key aspect to consider when thinking about participation in OSS
> > > projects is the journey a contributor makes, which starts before even
> > using
> > > the software. Each of the steps of the journey is only traversed by a
> > > minuscule number of people, so it is a good idea to have as many people
> > as
> > > possible lined up at the beginning of the process :) A quick guestimate
> > of
> > > the journey for a future contributor looks something like this:
> > >
> > > 1) They have to know off the project, which can be addressed by
> > > conferences, talks at universities and such.
> > > 2) They have to want to become users. This is really difficult to make
> > > happen externally :)
> > > 3) They have to be successful in their first use. Tutorials help with
> > that,
> > > and I think mxnet is doing a fantastic job there with the Gluon book.
> > > 4) They need to be able to "lurk" among other users: There needs to be
> a
> > > place where the users of the software come together and chat, complain
> > and
> > > help. Specifically, there should be *one* such place. The exact
> > mechanisms
> > > can differ, but I found that email lists still serve this use case
> well,
> > as
> > > they are sticky: Once subscribed, people stay informed :)
> > >
> > > If we get people to this stage, we can be proud: We just gained
> > > contributors: They are helping each other out, advocate for the project
> > and
> > > all. Now, the next step is for them to contribute to the code in
> addition
> > > to the community:
> > >
> > > 5) They have to know how to contribute, e.g. a bug report. And that
> first
> > > time they do it needs to be encouraging for future contributions.
> > > 6) They need to be able to observe the work as it happens, e.g. by
> > lurking
> > > on the mailing list. This 

Re: Refactoring MXNet scala code to use "org.apache.mxnet"

[Lupesko, Hagay]

Suneel,

I tend to think for this issue, GitHub issue is good enough and we do not need 
JIRA.
Can you clarify what is the advantage you see in using JIRA over GitHub issue 
for this specific case?

Thanks!
Hagay

On 1/4/18, 16:34, "Suneel Marthi"  wrote:

Jira has been around for a while -
https://issues.apache.org/jira/projects/MXNET/

switch to using jira

On Thu, Jan 4, 2018 at 7:31 PM, Roshani Nagmote 
wrote:

>  Hi,
>
> As currently, MXNet does not have Jira project, I have created github 
issue
> for now.
> https://github.com/apache/incubator-mxnet/issues/9315
>
> Will create the PR and link the issue there.
>
> Thanks,
> Roshani
>
> On Thu, Jan 4, 2018 at 3:08 PM, Naveen Swamy  wrote:
>
> > Hi Suneel,
> >
> > Did we decide that we will using Jira going forward? If not, can someone
> > summarize on the improvement email on the consensus and lets make it
> > universal and how to use it, what is expected, etc.,
> >
> > For the record, I like the idea of using Jira for more openness.
> >
> > Also, MXNet does not have Jira project, can you help creating one?
> >
> > Thanks, Naveen
> >
> >
> > On Thu, Jan 4, 2018 at 2:35 PM, Suneel Marthi 
> wrote:
> >
> > > Is there a Jira for this? Please create a Jira and reference that in
> the
> > PR
> > > for this.
> > >
> > > On Thu, Jan 4, 2018 at 5:16 PM, Roshani Nagmote <
> > roshaninagmo...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hello all,
> > > >
> > > > I am working on publishing mxnet-scala release to maven repository
> and
> > > as a
> > > > part of that, I will also be refactoring mxnet-scala
> code/tests/example
> > > and
> > > > docs to use "org.apache.mxnet" instead of "ml.dmlc.mxnet".
> > > >
> > > > Currently, MXNet-Scala
> > > >  library
> uses
> > > > "ml.dmlc.mxnet" packages. This work will change the way to import
> > modules
> > > > when using mxnet-scala package.
> > > >
> > > > *Old way:*
> > > >
> > > > scala> import ml.dmlc.mxnet._
> > > >import ml.dmlc.mxnet._scala> val arr = NDArray.ones(2, 3)
> > > >arr: ml.dmlc.mxnet.NDArray = ml.dmlc.mxnet.NDArray@f5e74790
> > > >
> > > > *New way:*
> > > >
> > > > scala> import org.apache.mxnet._
> > > >import org.apache.mxnet._
> > > > scala> val arr = NDArray.ones(2, 3)
> > > >arr: org.apache.mxnet.NDArray = org.apache.mxnet.NDArray@f5e74790
> > > >
> > > >
> > > > Please let me know if anyone has any thoughts or issues with this
> > change.
> > > >
> > > > Thanks,
> > > > Roshani
> > > >
> > >
> >
>

Re: Refactoring MXNet scala code to use "org.apache.mxnet"

[Suneel Marthi]

Jira has been around for a while -
https://issues.apache.org/jira/projects/MXNET/

switch to using jira

On Thu, Jan 4, 2018 at 7:31 PM, Roshani Nagmote 
wrote:

>  Hi,
>
> As currently, MXNet does not have Jira project, I have created github issue
> for now.
> https://github.com/apache/incubator-mxnet/issues/9315
>
> Will create the PR and link the issue there.
>
> Thanks,
> Roshani
>
> On Thu, Jan 4, 2018 at 3:08 PM, Naveen Swamy  wrote:
>
> > Hi Suneel,
> >
> > Did we decide that we will using Jira going forward? If not, can someone
> > summarize on the improvement email on the consensus and lets make it
> > universal and how to use it, what is expected, etc.,
> >
> > For the record, I like the idea of using Jira for more openness.
> >
> > Also, MXNet does not have Jira project, can you help creating one?
> >
> > Thanks, Naveen
> >
> >
> > On Thu, Jan 4, 2018 at 2:35 PM, Suneel Marthi 
> wrote:
> >
> > > Is there a Jira for this? Please create a Jira and reference that in
> the
> > PR
> > > for this.
> > >
> > > On Thu, Jan 4, 2018 at 5:16 PM, Roshani Nagmote <
> > roshaninagmo...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hello all,
> > > >
> > > > I am working on publishing mxnet-scala release to maven repository
> and
> > > as a
> > > > part of that, I will also be refactoring mxnet-scala
> code/tests/example
> > > and
> > > > docs to use "org.apache.mxnet" instead of "ml.dmlc.mxnet".
> > > >
> > > > Currently, MXNet-Scala
> > > >  library
> uses
> > > > "ml.dmlc.mxnet" packages. This work will change the way to import
> > modules
> > > > when using mxnet-scala package.
> > > >
> > > > *Old way:*
> > > >
> > > > scala> import ml.dmlc.mxnet._
> > > >import ml.dmlc.mxnet._scala> val arr = NDArray.ones(2, 3)
> > > >arr: ml.dmlc.mxnet.NDArray = ml.dmlc.mxnet.NDArray@f5e74790
> > > >
> > > > *New way:*
> > > >
> > > > scala> import org.apache.mxnet._
> > > >import org.apache.mxnet._
> > > > scala> val arr = NDArray.ones(2, 3)
> > > >arr: org.apache.mxnet.NDArray = org.apache.mxnet.NDArray@f5e74790
> > > >
> > > >
> > > > Please let me know if anyone has any thoughts or issues with this
> > change.
> > > >
> > > > Thanks,
> > > > Roshani
> > > >
> > >
> >
>

Re: Refactoring MXNet scala code to use "org.apache.mxnet"

[Nan Zhu]

anywhere to mark it as a breaking change in the latest version?

On Thu, Jan 4, 2018 at 2:16 PM, Roshani Nagmote 
wrote:

> Hello all,
>
> I am working on publishing mxnet-scala release to maven repository and as a
> part of that, I will also be refactoring mxnet-scala code/tests/example and
> docs to use "org.apache.mxnet" instead of "ml.dmlc.mxnet".
>
> Currently, MXNet-Scala
>  library uses
> "ml.dmlc.mxnet" packages. This work will change the way to import modules
> when using mxnet-scala package.
>
> *Old way:*
>
> scala> import ml.dmlc.mxnet._
>import ml.dmlc.mxnet._scala> val arr = NDArray.ones(2, 3)
>arr: ml.dmlc.mxnet.NDArray = ml.dmlc.mxnet.NDArray@f5e74790
>
> *New way:*
>
> scala> import org.apache.mxnet._
>import org.apache.mxnet._
> scala> val arr = NDArray.ones(2, 3)
>arr: org.apache.mxnet.NDArray = org.apache.mxnet.NDArray@f5e74790
>
>
> Please let me know if anyone has any thoughts or issues with this change.
>
> Thanks,
> Roshani
>

Re: Refactoring MXNet scala code to use "org.apache.mxnet"

[Suneel Marthi]

Is there a Jira for this? Please create a Jira and reference that in the PR
for this.

On Thu, Jan 4, 2018 at 5:16 PM, Roshani Nagmote 
wrote:

> Hello all,
>
> I am working on publishing mxnet-scala release to maven repository and as a
> part of that, I will also be refactoring mxnet-scala code/tests/example and
> docs to use "org.apache.mxnet" instead of "ml.dmlc.mxnet".
>
> Currently, MXNet-Scala
>  library uses
> "ml.dmlc.mxnet" packages. This work will change the way to import modules
> when using mxnet-scala package.
>
> *Old way:*
>
> scala> import ml.dmlc.mxnet._
>import ml.dmlc.mxnet._scala> val arr = NDArray.ones(2, 3)
>arr: ml.dmlc.mxnet.NDArray = ml.dmlc.mxnet.NDArray@f5e74790
>
> *New way:*
>
> scala> import org.apache.mxnet._
>import org.apache.mxnet._
> scala> val arr = NDArray.ones(2, 3)
>arr: org.apache.mxnet.NDArray = org.apache.mxnet.NDArray@f5e74790
>
>
> Please let me know if anyone has any thoughts or issues with this change.
>
> Thanks,
> Roshani
>

Re: Suggestions on how to increase community involvement on Apache MXNet incubating?

[Tianqi Chen]

I think the main point being raised is an easy way to know what is
happening and proposals.

Github has quite a lot of nice features with respect to this:

 - Issues make perfect sense in terms of discussing a single-point of
feature/bug and get feedback from anyone who can comment, additionally
being linked to pull request.
 - Issues are less useful for long-term roadmaps and discussions, there is
a feature called project(which is like trello) can be used for such things.

One problem we had in before is that roadmap issues get down the list
quickly and get deprecated by time without being closed. Aggressively close
issues and link them from a place that never sink, like project or wiki
might solve this issue.


Additionally, the dev mail list seems to serve a purpose to get to
developers, which can contain
- The discussion of major design points, before they actually being landed
on road-map
- general questions to raise people's attention to the certain issue being
progressed

Tianqi

On Thu, Jan 4, 2018 at 10:08 AM, Marco de Abreu <
marco.g.ab...@googlemail.com> wrote:

> Hello Markus,
>
> first of all, very good points!
>
> Regarding (1): In my opinion, we should always have some time of chat as
> this is the most convenient way for users and contributors to ask a quick
> question. I agree that proper discussions should be held on dev@, but
> sometimes a quick discussion in a chat is way more effective than writing
> dozens of emails - also, there might be some people who don't want to write
> an email to a mailing list just to ask a question that can be answered
> within 10 seconds. So instead I'd propose that we agree on one chat
> platforms for informal discussions and requests and that everything else
> gets put on dev@.
>
> -Marco
>
> On Thu, Jan 4, 2018 at 6:51 PM, Markus Weimer  wrote:
>
> > I really like most of what has been said, and the below might be a bit
> of a
> > repeat, but through a different lens.
> >
> > One key aspect to consider when thinking about participation in OSS
> > projects is the journey a contributor makes, which starts before even
> using
> > the software. Each of the steps of the journey is only traversed by a
> > minuscule number of people, so it is a good idea to have as many people
> as
> > possible lined up at the beginning of the process :) A quick guestimate
> of
> > the journey for a future contributor looks something like this:
> >
> > 1) They have to know off the project, which can be addressed by
> > conferences, talks at universities and such.
> > 2) They have to want to become users. This is really difficult to make
> > happen externally :)
> > 3) They have to be successful in their first use. Tutorials help with
> that,
> > and I think mxnet is doing a fantastic job there with the Gluon book.
> > 4) They need to be able to "lurk" among other users: There needs to be a
> > place where the users of the software come together and chat, complain
> and
> > help. Specifically, there should be *one* such place. The exact
> mechanisms
> > can differ, but I found that email lists still serve this use case well,
> as
> > they are sticky: Once subscribed, people stay informed :)
> >
> > If we get people to this stage, we can be proud: We just gained
> > contributors: They are helping each other out, advocate for the project
> and
> > all. Now, the next step is for them to contribute to the code in addition
> > to the community:
> >
> > 5) They have to know how to contribute, e.g. a bug report. And that first
> > time they do it needs to be encouraging for future contributions.
> > 6) They need to be able to observe the work as it happens, e.g. by
> lurking
> > on the mailing list. This gives context on what the community thinks
> about,
> > how it makes decisions, ... . Just like in RL, observing a community
> gives
> > confidence on how to engage with it.
> > 7) When they start thinking about contributing, the process to do so
> needs
> > to be clear. If step 6) worked, this doesn't even have to be very formal.
> >
> > Certainly, there are steps and hurdles that I forgot. There is a reason
> > whole PhD theses are written about participation in OSS. But thinking
> down
> > the lines of the journey should help us identify actions to be taken.
> >
> > With that descriptive stuff being said, allow me to be prescriptive with
> > some ideas:
> >
> > (1) Drop all communications channels besides the dev list.This greatly
> > simplifies lurking. My $DAY_JOB doesn't give me a chance to really follow
> > slack, for instance. But I read every email on this list.
> > (2) For those of you collocated in the same institution: Force yourself
> to
> > not talk about mxnet in the office or at lunch. Pretend not to be in the
> > same room or even on the same continent. Move all discussions onto the
> > list. This makes lurking easier, and, in my experience, improves the
> > quality of the technical discussions.
> > (3) Decide on one way for users to discuss among 

Re: Suggestions on how to increase community involvement on Apache MXNet incubating?

[Marco de Abreu]

Hello Markus,

first of all, very good points!

Regarding (1): In my opinion, we should always have some time of chat as
this is the most convenient way for users and contributors to ask a quick
question. I agree that proper discussions should be held on dev@, but
sometimes a quick discussion in a chat is way more effective than writing
dozens of emails - also, there might be some people who don't want to write
an email to a mailing list just to ask a question that can be answered
within 10 seconds. So instead I'd propose that we agree on one chat
platforms for informal discussions and requests and that everything else
gets put on dev@.

-Marco

On Thu, Jan 4, 2018 at 6:51 PM, Markus Weimer  wrote:

> I really like most of what has been said, and the below might be a bit of a
> repeat, but through a different lens.
>
> One key aspect to consider when thinking about participation in OSS
> projects is the journey a contributor makes, which starts before even using
> the software. Each of the steps of the journey is only traversed by a
> minuscule number of people, so it is a good idea to have as many people as
> possible lined up at the beginning of the process :) A quick guestimate of
> the journey for a future contributor looks something like this:
>
> 1) They have to know off the project, which can be addressed by
> conferences, talks at universities and such.
> 2) They have to want to become users. This is really difficult to make
> happen externally :)
> 3) They have to be successful in their first use. Tutorials help with that,
> and I think mxnet is doing a fantastic job there with the Gluon book.
> 4) They need to be able to "lurk" among other users: There needs to be a
> place where the users of the software come together and chat, complain and
> help. Specifically, there should be *one* such place. The exact mechanisms
> can differ, but I found that email lists still serve this use case well, as
> they are sticky: Once subscribed, people stay informed :)
>
> If we get people to this stage, we can be proud: We just gained
> contributors: They are helping each other out, advocate for the project and
> all. Now, the next step is for them to contribute to the code in addition
> to the community:
>
> 5) They have to know how to contribute, e.g. a bug report. And that first
> time they do it needs to be encouraging for future contributions.
> 6) They need to be able to observe the work as it happens, e.g. by lurking
> on the mailing list. This gives context on what the community thinks about,
> how it makes decisions, ... . Just like in RL, observing a community gives
> confidence on how to engage with it.
> 7) When they start thinking about contributing, the process to do so needs
> to be clear. If step 6) worked, this doesn't even have to be very formal.
>
> Certainly, there are steps and hurdles that I forgot. There is a reason
> whole PhD theses are written about participation in OSS. But thinking down
> the lines of the journey should help us identify actions to be taken.
>
> With that descriptive stuff being said, allow me to be prescriptive with
> some ideas:
>
> (1) Drop all communications channels besides the dev list.This greatly
> simplifies lurking. My $DAY_JOB doesn't give me a chance to really follow
> slack, for instance. But I read every email on this list.
> (2) For those of you collocated in the same institution: Force yourself to
> not talk about mxnet in the office or at lunch. Pretend not to be in the
> same room or even on the same continent. Move all discussions onto the
> list. This makes lurking easier, and, in my experience, improves the
> quality of the technical discussions.
> (3) Decide on one way for users to discuss among each other. Most Apache
> projects use email lists for it as well. Which, granted, is pretty old
> school.
>
> Thanks for reading this far, I did not have enough time to write less :)
>
> Markus
>
>
>
> On Thu, Jan 4, 2018 at 5:22 AM, Pedro Larroy  >
> wrote:
>
> > Agreed with Chris and Jeff. Googling for MXNet roadmap is
> > enlightening. Also the communication channels are disperse.
> > I would remove suggesting "Ask questions" in issues in the README.md
> > because this encourages inflation of issues that are just questions.
> >
> > We should link to the slack channel or discuss or mailing list in the
> > README and be clear on how to use those communication channels.
> >
> > More visibility on epics / roadmap in something like Trello? Roadmap
> > tagged issues right not don't seem to be really maintained.
> >
> > Explicitly asking in a TODO file or in the README or the Wiki on how
> > other people can contribute.
> > Having a list of "low hanging fruit" issues for newcomers to pick and
> > get familiar contributing to the project.
> > Making a blog post about how to contribute to MXNet, can be as simple
> > as how to use CLion to contribute to the project and send a patch...
> >
> > Just my thoughts.
> >

Re: Suggestions on how to increase community involvement on Apache MXNet incubating?

[Markus Weimer]

I really like most of what has been said, and the below might be a bit of a
repeat, but through a different lens.

One key aspect to consider when thinking about participation in OSS
projects is the journey a contributor makes, which starts before even using
the software. Each of the steps of the journey is only traversed by a
minuscule number of people, so it is a good idea to have as many people as
possible lined up at the beginning of the process :) A quick guestimate of
the journey for a future contributor looks something like this:

1) They have to know off the project, which can be addressed by
conferences, talks at universities and such.
2) They have to want to become users. This is really difficult to make
happen externally :)
3) They have to be successful in their first use. Tutorials help with that,
and I think mxnet is doing a fantastic job there with the Gluon book.
4) They need to be able to "lurk" among other users: There needs to be a
place where the users of the software come together and chat, complain and
help. Specifically, there should be *one* such place. The exact mechanisms
can differ, but I found that email lists still serve this use case well, as
they are sticky: Once subscribed, people stay informed :)

If we get people to this stage, we can be proud: We just gained
contributors: They are helping each other out, advocate for the project and
all. Now, the next step is for them to contribute to the code in addition
to the community:

5) They have to know how to contribute, e.g. a bug report. And that first
time they do it needs to be encouraging for future contributions.
6) They need to be able to observe the work as it happens, e.g. by lurking
on the mailing list. This gives context on what the community thinks about,
how it makes decisions, ... . Just like in RL, observing a community gives
confidence on how to engage with it.
7) When they start thinking about contributing, the process to do so needs
to be clear. If step 6) worked, this doesn't even have to be very formal.

Certainly, there are steps and hurdles that I forgot. There is a reason
whole PhD theses are written about participation in OSS. But thinking down
the lines of the journey should help us identify actions to be taken.

With that descriptive stuff being said, allow me to be prescriptive with
some ideas:

(1) Drop all communications channels besides the dev list.This greatly
simplifies lurking. My $DAY_JOB doesn't give me a chance to really follow
slack, for instance. But I read every email on this list.
(2) For those of you collocated in the same institution: Force yourself to
not talk about mxnet in the office or at lunch. Pretend not to be in the
same room or even on the same continent. Move all discussions onto the
list. This makes lurking easier, and, in my experience, improves the
quality of the technical discussions.
(3) Decide on one way for users to discuss among each other. Most Apache
projects use email lists for it as well. Which, granted, is pretty old
school.

Thanks for reading this far, I did not have enough time to write less :)

Markus



On Thu, Jan 4, 2018 at 5:22 AM, Pedro Larroy 
wrote:

> Agreed with Chris and Jeff. Googling for MXNet roadmap is
> enlightening. Also the communication channels are disperse.
> I would remove suggesting "Ask questions" in issues in the README.md
> because this encourages inflation of issues that are just questions.
>
> We should link to the slack channel or discuss or mailing list in the
> README and be clear on how to use those communication channels.
>
> More visibility on epics / roadmap in something like Trello? Roadmap
> tagged issues right not don't seem to be really maintained.
>
> Explicitly asking in a TODO file or in the README or the Wiki on how
> other people can contribute.
> Having a list of "low hanging fruit" issues for newcomers to pick and
> get familiar contributing to the project.
> Making a blog post about how to contribute to MXNet, can be as simple
> as how to use CLion to contribute to the project and send a patch...
>
> Just my thoughts.
>
> Pedro.
>
> On Wed, Jan 3, 2018 at 9:55 PM, Chris Olivier 
> wrote:
> > I suggest more transparency in the development process and requirement
> > definitions and grooming.
> >
> > Backlog wish-list on public wiki, which link to public JIRA epics or
> > stories, where people outside of Amazon can edit/comment on the items or
> > add items themselves.
> >
> >
> > On Wed, Jan 3, 2018 at 11:48 AM, Bhavin Thaker 
> > wrote:
> >
> >> Hi Team,
> >>
> >> Do you have any suggestions on how to increase community involvement and
> >> contributions including code additions/changes, bug-fixes/enhancements,
> >> documentation updates, tutorials, increased adoption, answering
> questions
> >> on Stackoverflow/discuss.mxnet.io, etc.?
> >>
> >> While I have asked multiple questions in the one question above, I am
> >> looking for more 

Re: [DISCUSS] Build OSX builds in CI (possibly with TravisCI).

[kellen sunderland]

Hope everyone had a good break.  Just wanted to check if there were further
thoughts on OSX builds.  Chris, did you have time to look into virtualizing
Mac OS?  Would it make sense for us to put something in place in the
interim e.g. the clang solution?

On Tue, Dec 12, 2017 at 7:59 PM, de Abreu, Marco  wrote:

> Thanks for looking into this, Chris! No hurries on that one, we’ll look
> into it next stage when we add new system- and build-configurations to the
> CI.
>
> On 12.12.17, 19:12, "Chris Olivier"  wrote:
>
> I am on vacation starting Thursday.
>
> On Tue, Dec 12, 2017 at 9:49 AM kellen sunderland <
> kellen.sunderl...@gmail.com> wrote:
>
> > Absolutely, let's do an investigation and see if it's possible to
> > virtualize.  Would you have time to look into it a bit further?
> >
> > On Tue, Dec 12, 2017 at 6:47 PM, Chris Olivier <
> cjolivie...@gmail.com>
> > wrote:
> >
> > > Don’t get me wrong, I’m not saying this Mac OS Jenkins solution is
> doable
> > > but I feel like we should investigate because the payoff would be
> large.
> > >
> > >
> > > On Tue, Dec 12, 2017 at 9:38 AM Chris Olivier <
> cjolivie...@gmail.com>
> > > wrote:
> > >
> > > > Apple’s Darwin OS Is recently open-sourced.
> > > > https://github.com/PureDarwin/PureDarwin
> > > >
> > > > How to convert this into a non-GUI VM I am not sure but I am
> willing to
> > > > bet that people have done it already.
> > > >
> > > > On Tue, Dec 12, 2017 at 9:16 AM kellen sunderland <
> > > > kellen.sunderl...@gmail.com> wrote:
> > > >
> > > >> It might be technically possible, but I think it would violate
> the
> > MacOS
> > > >> license: http://store.apple.com/Catalog/US/Images/MacOSX.htm
> > > >>
> > > >> "2. Permitted License Uses and Restrictions.
> > > >> A. This License allows you to install and use one copy of the
> Apple
> > > >> Software on a single Apple-labeled computer at a time. This
> License
> > does
> > > >> not allow the Apple Software to exist on more than one computer
> at a
> > > >> time,and you may not make the Apple Software available over a
> network
> > > >> where
> > > >> it could be used by multiple computers at the same time. You
> may make
> > > one
> > > >> copy of the Apple Software (excluding the Boot ROM code) in
> > > >> machine-readable form for backup purposes only; provided that
> the
> > backup
> > > >> copy must include all copyright or other proprietary notices
> contained
> > > on
> > > >> the original. "
> > > >>
> > > >> I could be wrong though, does anyone know the details of MacOS
> > > licensing /
> > > >> virtualization?
> > > >>
> > > >> On Tue, Dec 12, 2017 at 6:10 PM, Chris Olivier <
> cjolivie...@gmail.com
> > >
> > > >> wrote:
> > > >>
> > > >> > googling seems to be full of running OSX (and even
> open-sourced
> > > >> PureDarwin)
> > > >> > in VMs. One could conceivably run a VM on an EC2 instance,
> right?
> > > >> >
> > > >> > On Tue, Dec 12, 2017 at 9:01 AM kellen sunderland <
> > > >> > kellen.sunderl...@gmail.com> wrote:
> > > >> >
> > > >> > > It would be ideal if we could cover OSX in Jenkins, but the
> only
> > > >> solution
> > > >> > > that I'm aware of would require physical machines to be the
> > workers.
> > > >> I
> > > >> > > would be weakly opposed to having physical servers running
> on PRs.
> > > >> The
> > > >> > > downsides that I see in order of importance:
> > > >> > >
> > > >> > > -  We can't autoscale physical hardware.   If we find that
> the
> > load
> > > is
> > > >> > too
> > > >> > > high we have to buy more machines.
> > > >> > > -  Security would be tricky, as they'd have to be connected
> to the
> > > >> > internet
> > > >> > > and then to our Jekins master instance.  Connecting via a
> wired
> > > >> network
> > > >> > > would probably not be possible on most corporate networks
> as these
> > > >> > machines
> > > >> > > are by definition running arbitrary code from the
> internet.  Many
> > > >> > corporate
> > > >> > > sites have public wifi that this machine could potentially
> connect
> > > to,
> > > >> > but
> > > >> > > then our PRs start failing if the wifi disconnects
> temporarily.
> > To
> > > >> > connect
> > > >> > > to the master we would need to setup a vpn solution with
> endpoints
> > > in
> > > >> our
> > > >> > > vpc on AWS.  This is possible but would probably require a
> lot of
> > > >> > security
> > > >> > > work.
> > > >> > > -  We can't just create a simple startup script or yaml
> file that
> > is
> > > >> > > checked into GitHub to manage the machine.  Someone will
> actually
> > > >> have to
> > > >> > > 

Re: Suggestions on how to increase community involvement on Apache MXNet incubating?

[Pedro Larroy]

Agreed with Chris and Jeff. Googling for MXNet roadmap is
enlightening. Also the communication channels are disperse.
I would remove suggesting "Ask questions" in issues in the README.md
because this encourages inflation of issues that are just questions.

We should link to the slack channel or discuss or mailing list in the
README and be clear on how to use those communication channels.

More visibility on epics / roadmap in something like Trello? Roadmap
tagged issues right not don't seem to be really maintained.

Explicitly asking in a TODO file or in the README or the Wiki on how
other people can contribute.
Having a list of "low hanging fruit" issues for newcomers to pick and
get familiar contributing to the project.
Making a blog post about how to contribute to MXNet, can be as simple
as how to use CLion to contribute to the project and send a patch...

Just my thoughts.

Pedro.

On Wed, Jan 3, 2018 at 9:55 PM, Chris Olivier  wrote:
> I suggest more transparency in the development process and requirement
> definitions and grooming.
>
> Backlog wish-list on public wiki, which link to public JIRA epics or
> stories, where people outside of Amazon can edit/comment on the items or
> add items themselves.
>
>
> On Wed, Jan 3, 2018 at 11:48 AM, Bhavin Thaker 
> wrote:
>
>> Hi Team,
>>
>> Do you have any suggestions on how to increase community involvement and
>> contributions including code additions/changes, bug-fixes/enhancements,
>> documentation updates, tutorials, increased adoption, answering questions
>> on Stackoverflow/discuss.mxnet.io, etc.?
>>
>> While I have asked multiple questions in the one question above, I am
>> looking for more ideas or thoughts.
>>
>> Cheers,
>> Bhavin Thaker.
>>