Graduation

[Gunnar Tapper <ta...@gmail.com>]

Hi,

I might be getting ahead of myself on involvement but I thought I'd share a
few lessons I learnt about Apache incubation...

1. The main focus of Apache is the community and the Apache Way.

When you first get involved, it's a bit hard to understand this since
you're likely used to drive product and product value. You do need an
interesting project for people to get involved (what can be cooler that
IoT!) but Apache cares more that we build a community, get releases out,
and so on.

2. Distribution list are everything

ALL (and I mean ALL) discussions and decisions need to happen on the iota
mailing lists. These mailing lists ARE the record of the project and
indicates activity.

Of course, you need Stack Overflow, Slack, and other things to build a
community but they don't quite "count."

Further, we need to ensure that both user and dev lists are active. The
easiest way to think about user is to go "would a user benefit from this?"
A good example is discussing how to install the product for documentation
-- have that discussion on the user list since it allows people to find
install instructions before the website has proper documentation.

3. Release often

It takes a few releases to dot all the Is and cross all the Ts on releasing
the Apache Way. Don't worry about quality in the beginning, worry about
following the processes and getting passed on the legal stuff.

Next, move to a stable/bleeding edge model so that you can continue to
release often. You'll find that the major Hadoop projects follow this model
so that people can help testing without having to build the product and to
ensure constant project activity.

I recommend a scheduled train model every N weeks.

4. Mentors have day jobs

The mentors' job is to help guide the incubator to graduation. GUIDE is the
operating word here so don't expect hands-on help unless the mentors have
time for hands-on. Further, mentors are often involved with several
incubators.

5. You have to excite people

People get involved when they think that a project is cool. It's very much
a fashion thing in my opinion. For example, I'm getting involved in iota
because I love the idea of IoT and want to be able to build IoT solutions.
Plus, I think that I can help.

My point here is that you have to sell the project as much as you sell
products developed on top of it. We need presentations, videos, Twitter,
easy ways to get involved, and so on.

6. Lead with open source

Ensure that whatever solution you're building on top of iota relies on the
fact that the required functions are put into iota and released so that the
solution DEPENDS on iota release X. It's the normal pecking order: OS
before database before middle ware before applications.

7. You are an individual

You may be paid by a company but to Apache, you are an individual that
expresses your opinions and makes your contributions.

This was very hard for me in the beginning because I was used to always
communicate in we form. Now, I've learnt to use "I" when I am expressing
what I think and "we" when I am referring to the project as a whole.

I hope this helps.

-- 
Thanks,

Gunnar
*If you think you can you can, if you think you can't you're right.*

Re: Graduation

[Gunnar Tapper <ta...@gmail.com>]

Hi

I assume that Tony or on of you other committers have user admin
permissions for the wiki and can add me?

Thanks,

Gunnar

On Mon, Feb 6, 2017 at 11:23 PM, Justin Mclean <ju...@classsoftware.com>
wrote:

> Hi,
>
> > Have you had a chance to add me as an editor of the iota wiki pages? I
> just checked and I don't have the necessary permissions.
>
> I did and looks like I don't have permission to be able to add you, sorry
> someone else will need to do it for you.
>
> Thanks,
> Justin




-- 
Thanks,

Gunnar
*If you think you can you can, if you think you can't you're right.*

Re: Graduation

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Have you had a chance to add me as an editor of the iota wiki pages? I just checked and I don't have the necessary permissions.

I did and looks like I don't have permission to be able to add you, sorry someone else will need to do it for you.

Thanks,
Justin

Re: Can one of the iota mentors add Gunnar as an editor to the iota wiki pages on confluence?

[Tony Faustini <to...@litbit.com>]

Hi Daniel, Sterling or Hadrian,  I don’t seem to have admin privileges to add tapper. I don’t see the admin cog as I do when I use admin privileges on our company’s Confluence wiki.
Can some help add user ID : gtapper to enable Gunnar Tapper to edit the iota confluence pages?  Or explain to me how I might do this. Perhaps we need someone in infrastructure to help?

Thanks
-Tony


> On Feb 7, 2017, at 8:41 AM, Gunnar Tapper <ta...@gmail.com> wrote:
> 
> Hi Tony,
> 
> No luck, I still can't edit the wiki pages.
> 
> Thanks,
> 
> Gunnar
> 
> On Tue, Feb 7, 2017 at 1:37 AM, Tony Faustini <tony@litbit.com <ma...@litbit.com>> wrote:
> Hi Gunnar please try again I added you. Please verify.
> -Tony
> 
>> On Feb 6, 2017, at 10:17 PM, Gunnar Tapper <tapper.gunnar@gmail.com <ma...@gmail.com>> wrote:
>> 
>> Hi Justin:
>> 
>> Have you had a chance to add me as an editor of the iota wiki pages? I just checked and I don't have the necessary permissions.
>> 
>> My user ID is: gtapper
>> 
>> Tack,
>> 
>> Gunnar
>> 
>> On Sun, Feb 5, 2017 at 5:45 PM, Gunnar Tapper <tapper.gunnar@gmail.com <ma...@gmail.com>> wrote:
>> Hi Tony,
>> 
>> As Justin states, I've not earned the status of committer yet. That comes with time. By getting involved, I am contributing, which means that I am an iota contributor. Contribution comes in many forms: presenting, using, testing, asking questions, coding, etc. We'll cover that in the iota Contributor's Guide.
>> 
>> IMO, documentation should be separated on the wiki and in the source tree. Here's my rule-of-thumb:
>> 
>> 1. Release-dependent documentation goes with the code since it needs to be versioned. Change this documentation as part of code checkin.
>> 2. Contributor Guides, examples, project management stuff, etc. goes on the wiki. No versioned information is expected so the text has to handle situations such as "build like this in version 1; build like this in version 2."
>> 
>> I also suggest a jira for "we need a user friendly tool similar to Java Studio or IFTTT" so that the idea doesn't get lost. I also suggest a wiki page that provides a list of get-your-feet-wet Jiras for people that want to get involved. Nothing like early success that you know others will find useful.
>> 
>> So, let's start out with the contributor's guide. I'll set up a basic structure and then we can add in info on the basics: where is stuff, what's needed to build, how to build, how to run, and to test, and how to contribute new/modified function. After that, then I suggest that we try to work through a release ensuring that all requirements are met. Justin will be a great help here because he knows the ins and out of what's required.
>> 
>> Thoughts?
>> 
>> Thanks,
>> 
>> Gunnar
>> 
>> On Sun, Feb 5, 2017 at 1:03 PM, Tony Faustini <tony@litbit.com <ma...@litbit.com>> wrote:
>> Gunnar you are not getting ahead of yourself - We the project are behind and with your help we can get up to speed and get out a release. I am committed to getting this release out as soon as I can. With help from you and other individuals we can do this. The vision is vast and the area is exciting (IoT!). It begins with iota but there is a lot more after that. I am looking forward in learning more about the Apache Way as are other committers with limited Apache experience.
>> 
>> I would like to get you access to the iota confluence pages and I would hope you could replicate the generic part of the framework you setup for Trafodian. Once a framework has been setup I and other r committers will begin to fill in the iota specific parts. I am sure you will be able to contribute in these specifics once you have some experience with iota. As a committer can I give you permission to edit the iota pages? Do we need to add you as an iota committer? How do we get you access?
>> 
>> I and Barbara Malta Gomes can work on a basic document that will walk users/developers through the process of installing iota on their PC so they can begin to experience iota and hopefully start building performers that they can contributed to the iota project. The document will explain how to install and build iota using SBT command-line style , it will explain how to write a basic performer and run it on their PC. 
>> 
>> I suggest we discuss and get clarity on what belongs on dev and what belongs on users. Here is a strawman proposal
>> 1) Developers - installation, build, iota engine, and iota performers, explanations on how to write performers
>> 2) Users - install iota and use orchestrations to build robust applications with no knowledge of Java/Scala/Akka. Just need to understand how to how to write an orchestration which is essential just a json object. [ Hint; great opportunity for someone to write a user friendly tool similar to Java Studio or IFTTT (If this then that) to generate and run iota orchestrations that are json objects - not too user friendly]
>> Is this the Apache Way?
>> 
>> We should get involved in the emerging IoT mini conference in Miami - we should have a release done before that conference and an iota presentation ready.
>> 
>> Gunnar I want to fix  "Also, it'd be good to fix the link in the "Apache" row on the incubator page so that it works: http://incubator.apache.org/projects/iota.html <http://incubator.apache.org/projects/iota.html>”
>> Not sure what you mean - is the link not working or it is pointing to the wrong place?
>> 
>> Thanks
>> -Tony
>> 
>>> On Feb 5, 2017, at 11:13 AM, Gunnar Tapper <tapper.gunnar@gmail.com <ma...@gmail.com>> wrote:
>>> 
>>> Hi,
>>> 
>>> I might be getting ahead of myself on involvement but I thought I'd share a few lessons I learnt about Apache incubation... 
>>> 
>>> 1. The main focus of Apache is the community and the Apache Way. 
>>> 
>>> When you first get involved, it's a bit hard to understand this since you're likely used to drive product and product value. You do need an interesting project for people to get involved (what can be cooler that IoT!) but Apache cares more that we build a community, get releases out, and so on.
>>> 
>>> 2. Distribution list are everything
>>> 
>>> ALL (and I mean ALL) discussions and decisions need to happen on the iota mailing lists. These mailing lists ARE the record of the project and indicates activity.
>>> 
>>> Of course, you need Stack Overflow, Slack, and other things to build a community but they don't quite "count." 
>>> 
>>> Further, we need to ensure that both user and dev lists are active. The easiest way to think about user is to go "would a user benefit from this?" A good example is discussing how to install the product for documentation -- have that discussion on the user list since it allows people to find install instructions before the website has proper documentation.
>>> 
>>> 3. Release often
>>> 
>>> It takes a few releases to dot all the Is and cross all the Ts on releasing the Apache Way. Don't worry about quality in the beginning, worry about following the processes and getting passed on the legal stuff.
>>> 
>>> Next, move to a stable/bleeding edge model so that you can continue to release often. You'll find that the major Hadoop projects follow this model so that people can help testing without having to build the product and to ensure constant project activity. 
>>> 
>>> I recommend a scheduled train model every N weeks.
>>> 
>>> 4. Mentors have day jobs
>>> 
>>> The mentors' job is to help guide the incubator to graduation. GUIDE is the operating word here so don't expect hands-on help unless the mentors have time for hands-on. Further, mentors are often involved with several incubators.
>>> 
>>> 5. You have to excite people
>>> 
>>> People get involved when they think that a project is cool. It's very much a fashion thing in my opinion. For example, I'm getting involved in iota because I love the idea of IoT and want to be able to build IoT solutions. Plus, I think that I can help.
>>> 
>>> My point here is that you have to sell the project as much as you sell products developed on top of it. We need presentations, videos, Twitter, easy ways to get involved, and so on. 
>>> 
>>> 6. Lead with open source
>>> 
>>> Ensure that whatever solution you're building on top of iota relies on the fact that the required functions are put into iota and released so that the solution DEPENDS on iota release X. It's the normal pecking order: OS before database before middle ware before applications.
>>> 
>>> 7. You are an individual
>>> 
>>> You may be paid by a company but to Apache, you are an individual that expresses your opinions and makes your contributions.
>>> 
>>> This was very hard for me in the beginning because I was used to always communicate in we form. Now, I've learnt to use "I" when I am expressing what I think and "we" when I am referring to the project as a whole.
>>> 
>>> I hope this helps. 
>>> 
>>> -- 
>>> Thanks,
>>> 
>>> Gunnar
>>> If you think you can you can, if you think you can't you're right.
>> 
>> 
>> 
>> 
>> -- 
>> Thanks,
>> 
>> Gunnar
>> If you think you can you can, if you think you can't you're right.
>> 
>> 
>> 
>> -- 
>> Thanks,
>> 
>> Gunnar
>> If you think you can you can, if you think you can't you're right.
> 
> 
> 
> 
> -- 
> Thanks,
> 
> Gunnar
> If you think you can you can, if you think you can't you're right.

Re: Graduation

[Gunnar Tapper <ta...@gmail.com>]

Hi Tony,

No luck, I still can't edit the wiki pages.

Thanks,

Gunnar

On Tue, Feb 7, 2017 at 1:37 AM, Tony Faustini <to...@litbit.com> wrote:

> Hi Gunnar please try again I added you. Please verify.
> -Tony
>
> On Feb 6, 2017, at 10:17 PM, Gunnar Tapper <ta...@gmail.com>
> wrote:
>
> Hi Justin:
>
> Have you had a chance to add me as an editor of the iota wiki pages? I
> just checked and I don't have the necessary permissions.
>
> My user ID is: gtapper
>
> Tack,
>
> Gunnar
>
> On Sun, Feb 5, 2017 at 5:45 PM, Gunnar Tapper <ta...@gmail.com>
> wrote:
>
>> Hi Tony,
>>
>> As Justin states, I've not earned the status of committer yet. That comes
>> with time. By getting involved, I am contributing, which means that I am an
>> iota contributor. Contribution comes in many forms: presenting, using,
>> testing, asking questions, coding, etc. We'll cover that in the iota
>> Contributor's Guide.
>>
>> IMO, documentation should be separated on the wiki and in the source
>> tree. Here's my rule-of-thumb:
>>
>> 1. Release-dependent documentation goes with the code since it needs to
>> be versioned. Change this documentation as part of code checkin.
>> 2. Contributor Guides, examples, project management stuff, etc. goes on
>> the wiki. No versioned information is expected so the text has to handle
>> situations such as "build like this in version 1; build like this in
>> version 2."
>>
>> I also suggest a jira for "we need a user friendly tool similar to Java
>> Studio or IFTTT" so that the idea doesn't get lost. I also suggest a wiki
>> page that provides a list of get-your-feet-wet Jiras for people that want
>> to get involved. Nothing like early success that you know others will find
>> useful.
>>
>> So, let's start out with the contributor's guide. I'll set up a basic
>> structure and then we can add in info on the basics: where is stuff, what's
>> needed to build, how to build, how to run, and to test, and how to
>> contribute new/modified function. After that, then I suggest that we try to
>> work through a release ensuring that all requirements are met. Justin will
>> be a great help here because he knows the ins and out of what's required.
>>
>> Thoughts?
>>
>> Thanks,
>>
>> Gunnar
>>
>> On Sun, Feb 5, 2017 at 1:03 PM, Tony Faustini <to...@litbit.com> wrote:
>>
>>> Gunnar you are not getting ahead of yourself - We the project are behind
>>> and with your help we can get up to speed and get out a release. I am
>>> committed to getting this release out as soon as I can. With help from you
>>> and other individuals we can do this. The vision is vast and the area is
>>> exciting (IoT!). It begins with iota but there is a lot more after that. I
>>> am looking forward in learning more about the Apache Way as are other
>>> committers with limited Apache experience.
>>>
>>> I would like to get you access to the iota confluence pages and I would
>>> hope you could replicate the generic part of the framework you setup for
>>> Trafodian. Once a framework has been setup I and other r committers will
>>> begin to fill in the iota specific parts. I am sure you will be able to
>>> contribute in these specifics once you have some experience with iota. As a
>>> committer can I give you permission to edit the iota pages? Do we need to
>>> add you as an iota committer? How do we get you access?
>>>
>>> I and Barbara Malta Gomes can work on a basic document that will walk
>>> users/developers through the process of installing iota on their PC so they
>>> can begin to experience iota and hopefully start building performers that
>>> they can contributed to the iota project. The document will explain how to
>>> install and build iota using SBT command-line style , it will explain how
>>> to write a basic performer and run it on their PC.
>>>
>>> I suggest we discuss and get clarity on what belongs on dev and what
>>> belongs on users. Here is a strawman proposal
>>> 1) Developers - installation, build, iota engine, and iota performers,
>>> explanations on how to write performers
>>> 2) Users - install iota and use orchestrations to build robust
>>> applications with no knowledge of Java/Scala/Akka. Just need to understand
>>> how to how to write an orchestration which is essential just a json object.
>>> [ Hint; great opportunity for someone to write a user friendly tool similar
>>> to Java Studio or IFTTT (If this then that) to generate and run iota
>>> orchestrations that are json objects - not too user friendly]
>>> Is this the Apache Way?
>>>
>>> We should get involved in the emerging IoT mini conference in Miami - we
>>> should have a release done before that conference and an iota presentation
>>> ready.
>>>
>>> Gunnar I want to fix  "Also, it'd be good to fix the link in the
>>> "Apache" row on the incubator page so that it works:
>>> http://incubator.apache.org/projects/iota.html”
>>> Not sure what you mean - is the link not working or it is pointing to
>>> the wrong place?
>>>
>>> Thanks
>>> -Tony
>>>
>>> On Feb 5, 2017, at 11:13 AM, Gunnar Tapper <ta...@gmail.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>> I might be getting ahead of myself on involvement but I thought I'd
>>> share a few lessons I learnt about Apache incubation...
>>>
>>> 1. The main focus of Apache is the community and the Apache Way.
>>>
>>> When you first get involved, it's a bit hard to understand this since
>>> you're likely used to drive product and product value. You do need an
>>> interesting project for people to get involved (what can be cooler that
>>> IoT!) but Apache cares more that we build a community, get releases out,
>>> and so on.
>>>
>>> 2. Distribution list are everything
>>>
>>> ALL (and I mean ALL) discussions and decisions need to happen on the
>>> iota mailing lists. These mailing lists ARE the record of the project and
>>> indicates activity.
>>>
>>> Of course, you need Stack Overflow, Slack, and other things to build a
>>> community but they don't quite "count."
>>>
>>> Further, we need to ensure that both user and dev lists are active. The
>>> easiest way to think about user is to go "would a user benefit from this?"
>>> A good example is discussing how to install the product for documentation
>>> -- have that discussion on the user list since it allows people to find
>>> install instructions before the website has proper documentation.
>>>
>>> 3. Release often
>>>
>>> It takes a few releases to dot all the Is and cross all the Ts on
>>> releasing the Apache Way. Don't worry about quality in the beginning, worry
>>> about following the processes and getting passed on the legal stuff.
>>>
>>> Next, move to a stable/bleeding edge model so that you can continue to
>>> release often. You'll find that the major Hadoop projects follow this model
>>> so that people can help testing without having to build the product and to
>>> ensure constant project activity.
>>>
>>> I recommend a scheduled train model every N weeks.
>>>
>>> 4. Mentors have day jobs
>>>
>>> The mentors' job is to help guide the incubator to graduation. GUIDE is
>>> the operating word here so don't expect hands-on help unless the mentors
>>> have time for hands-on. Further, mentors are often involved with several
>>> incubators.
>>>
>>> 5. You have to excite people
>>>
>>> People get involved when they think that a project is cool. It's very
>>> much a fashion thing in my opinion. For example, I'm getting involved in
>>> iota because I love the idea of IoT and want to be able to build IoT
>>> solutions. Plus, I think that I can help.
>>>
>>> My point here is that you have to sell the project as much as you sell
>>> products developed on top of it. We need presentations, videos, Twitter,
>>> easy ways to get involved, and so on.
>>>
>>> 6. Lead with open source
>>>
>>> Ensure that whatever solution you're building on top of iota relies on
>>> the fact that the required functions are put into iota and released so that
>>> the solution DEPENDS on iota release X. It's the normal pecking order: OS
>>> before database before middle ware before applications.
>>>
>>> 7. You are an individual
>>>
>>> You may be paid by a company but to Apache, you are an individual that
>>> expresses your opinions and makes your contributions.
>>>
>>> This was very hard for me in the beginning because I was used to always
>>> communicate in we form. Now, I've learnt to use "I" when I am expressing
>>> what I think and "we" when I am referring to the project as a whole.
>>>
>>> I hope this helps.
>>>
>>> --
>>> Thanks,
>>>
>>> Gunnar
>>> *If you think you can you can, if you think you can't you're right.*
>>>
>>>
>>>
>>
>>
>> --
>> Thanks,
>>
>> Gunnar
>> *If you think you can you can, if you think you can't you're right.*
>>
>
>
>
> --
> Thanks,
>
> Gunnar
> *If you think you can you can, if you think you can't you're right.*
>
>
>


-- 
Thanks,

Gunnar
*If you think you can you can, if you think you can't you're right.*

Re: Graduation

[Tony Faustini <to...@litbit.com>]

Hi Gunnar please try again I added you. Please verify.
-Tony

> On Feb 6, 2017, at 10:17 PM, Gunnar Tapper <ta...@gmail.com> wrote:
> 
> Hi Justin:
> 
> Have you had a chance to add me as an editor of the iota wiki pages? I just checked and I don't have the necessary permissions.
> 
> My user ID is: gtapper
> 
> Tack,
> 
> Gunnar
> 
> On Sun, Feb 5, 2017 at 5:45 PM, Gunnar Tapper <tapper.gunnar@gmail.com <ma...@gmail.com>> wrote:
> Hi Tony,
> 
> As Justin states, I've not earned the status of committer yet. That comes with time. By getting involved, I am contributing, which means that I am an iota contributor. Contribution comes in many forms: presenting, using, testing, asking questions, coding, etc. We'll cover that in the iota Contributor's Guide.
> 
> IMO, documentation should be separated on the wiki and in the source tree. Here's my rule-of-thumb:
> 
> 1. Release-dependent documentation goes with the code since it needs to be versioned. Change this documentation as part of code checkin.
> 2. Contributor Guides, examples, project management stuff, etc. goes on the wiki. No versioned information is expected so the text has to handle situations such as "build like this in version 1; build like this in version 2."
> 
> I also suggest a jira for "we need a user friendly tool similar to Java Studio or IFTTT" so that the idea doesn't get lost. I also suggest a wiki page that provides a list of get-your-feet-wet Jiras for people that want to get involved. Nothing like early success that you know others will find useful.
> 
> So, let's start out with the contributor's guide. I'll set up a basic structure and then we can add in info on the basics: where is stuff, what's needed to build, how to build, how to run, and to test, and how to contribute new/modified function. After that, then I suggest that we try to work through a release ensuring that all requirements are met. Justin will be a great help here because he knows the ins and out of what's required.
> 
> Thoughts?
> 
> Thanks,
> 
> Gunnar
> 
> On Sun, Feb 5, 2017 at 1:03 PM, Tony Faustini <tony@litbit.com <ma...@litbit.com>> wrote:
> Gunnar you are not getting ahead of yourself - We the project are behind and with your help we can get up to speed and get out a release. I am committed to getting this release out as soon as I can. With help from you and other individuals we can do this. The vision is vast and the area is exciting (IoT!). It begins with iota but there is a lot more after that. I am looking forward in learning more about the Apache Way as are other committers with limited Apache experience.
> 
> I would like to get you access to the iota confluence pages and I would hope you could replicate the generic part of the framework you setup for Trafodian. Once a framework has been setup I and other r committers will begin to fill in the iota specific parts. I am sure you will be able to contribute in these specifics once you have some experience with iota. As a committer can I give you permission to edit the iota pages? Do we need to add you as an iota committer? How do we get you access?
> 
> I and Barbara Malta Gomes can work on a basic document that will walk users/developers through the process of installing iota on their PC so they can begin to experience iota and hopefully start building performers that they can contributed to the iota project. The document will explain how to install and build iota using SBT command-line style , it will explain how to write a basic performer and run it on their PC. 
> 
> I suggest we discuss and get clarity on what belongs on dev and what belongs on users. Here is a strawman proposal
> 1) Developers - installation, build, iota engine, and iota performers, explanations on how to write performers
> 2) Users - install iota and use orchestrations to build robust applications with no knowledge of Java/Scala/Akka. Just need to understand how to how to write an orchestration which is essential just a json object. [ Hint; great opportunity for someone to write a user friendly tool similar to Java Studio or IFTTT (If this then that) to generate and run iota orchestrations that are json objects - not too user friendly]
> Is this the Apache Way?
> 
> We should get involved in the emerging IoT mini conference in Miami - we should have a release done before that conference and an iota presentation ready.
> 
> Gunnar I want to fix  "Also, it'd be good to fix the link in the "Apache" row on the incubator page so that it works: http://incubator.apache.org/projects/iota.html <http://incubator.apache.org/projects/iota.html>”
> Not sure what you mean - is the link not working or it is pointing to the wrong place?
> 
> Thanks
> -Tony
> 
>> On Feb 5, 2017, at 11:13 AM, Gunnar Tapper <tapper.gunnar@gmail.com <ma...@gmail.com>> wrote:
>> 
>> Hi,
>> 
>> I might be getting ahead of myself on involvement but I thought I'd share a few lessons I learnt about Apache incubation... 
>> 
>> 1. The main focus of Apache is the community and the Apache Way. 
>> 
>> When you first get involved, it's a bit hard to understand this since you're likely used to drive product and product value. You do need an interesting project for people to get involved (what can be cooler that IoT!) but Apache cares more that we build a community, get releases out, and so on.
>> 
>> 2. Distribution list are everything
>> 
>> ALL (and I mean ALL) discussions and decisions need to happen on the iota mailing lists. These mailing lists ARE the record of the project and indicates activity.
>> 
>> Of course, you need Stack Overflow, Slack, and other things to build a community but they don't quite "count." 
>> 
>> Further, we need to ensure that both user and dev lists are active. The easiest way to think about user is to go "would a user benefit from this?" A good example is discussing how to install the product for documentation -- have that discussion on the user list since it allows people to find install instructions before the website has proper documentation.
>> 
>> 3. Release often
>> 
>> It takes a few releases to dot all the Is and cross all the Ts on releasing the Apache Way. Don't worry about quality in the beginning, worry about following the processes and getting passed on the legal stuff.
>> 
>> Next, move to a stable/bleeding edge model so that you can continue to release often. You'll find that the major Hadoop projects follow this model so that people can help testing without having to build the product and to ensure constant project activity. 
>> 
>> I recommend a scheduled train model every N weeks.
>> 
>> 4. Mentors have day jobs
>> 
>> The mentors' job is to help guide the incubator to graduation. GUIDE is the operating word here so don't expect hands-on help unless the mentors have time for hands-on. Further, mentors are often involved with several incubators.
>> 
>> 5. You have to excite people
>> 
>> People get involved when they think that a project is cool. It's very much a fashion thing in my opinion. For example, I'm getting involved in iota because I love the idea of IoT and want to be able to build IoT solutions. Plus, I think that I can help.
>> 
>> My point here is that you have to sell the project as much as you sell products developed on top of it. We need presentations, videos, Twitter, easy ways to get involved, and so on. 
>> 
>> 6. Lead with open source
>> 
>> Ensure that whatever solution you're building on top of iota relies on the fact that the required functions are put into iota and released so that the solution DEPENDS on iota release X. It's the normal pecking order: OS before database before middle ware before applications.
>> 
>> 7. You are an individual
>> 
>> You may be paid by a company but to Apache, you are an individual that expresses your opinions and makes your contributions.
>> 
>> This was very hard for me in the beginning because I was used to always communicate in we form. Now, I've learnt to use "I" when I am expressing what I think and "we" when I am referring to the project as a whole.
>> 
>> I hope this helps. 
>> 
>> -- 
>> Thanks,
>> 
>> Gunnar
>> If you think you can you can, if you think you can't you're right.
> 
> 
> 
> 
> -- 
> Thanks,
> 
> Gunnar
> If you think you can you can, if you think you can't you're right.
> 
> 
> 
> -- 
> Thanks,
> 
> Gunnar
> If you think you can you can, if you think you can't you're right.

Re: Graduation

[Tony Faustini <to...@litbit.com>]

Hi Gunnar, I agree with your points 1 and 2 below. We can also add the Jira tickets suggested. 

-Tony


> On Feb 6, 2017, at 10:17 PM, Gunnar Tapper <ta...@gmail.com> wrote:
> 
> Hi Justin:
> 
> Have you had a chance to add me as an editor of the iota wiki pages? I just checked and I don't have the necessary permissions.
> 
> My user ID is: gtapper
> 
> Tack,
> 
> Gunnar
> 
> On Sun, Feb 5, 2017 at 5:45 PM, Gunnar Tapper <tapper.gunnar@gmail.com <ma...@gmail.com>> wrote:
> Hi Tony,
> 
> As Justin states, I've not earned the status of committer yet. That comes with time. By getting involved, I am contributing, which means that I am an iota contributor. Contribution comes in many forms: presenting, using, testing, asking questions, coding, etc. We'll cover that in the iota Contributor's Guide.
> 
> IMO, documentation should be separated on the wiki and in the source tree. Here's my rule-of-thumb:
> 
> 1. Release-dependent documentation goes with the code since it needs to be versioned. Change this documentation as part of code checkin.
> 2. Contributor Guides, examples, project management stuff, etc. goes on the wiki. No versioned information is expected so the text has to handle situations such as "build like this in version 1; build like this in version 2."
> 
> I also suggest a jira for "we need a user friendly tool similar to Java Studio or IFTTT" so that the idea doesn't get lost. I also suggest a wiki page that provides a list of get-your-feet-wet Jiras for people that want to get involved. Nothing like early success that you know others will find useful.
> 
> So, let's start out with the contributor's guide. I'll set up a basic structure and then we can add in info on the basics: where is stuff, what's needed to build, how to build, how to run, and to test, and how to contribute new/modified function. After that, then I suggest that we try to work through a release ensuring that all requirements are met. Justin will be a great help here because he knows the ins and out of what's required.
> 
> Thoughts?
> 
> Thanks,
> 
> Gunnar
> 
> On Sun, Feb 5, 2017 at 1:03 PM, Tony Faustini <tony@litbit.com <ma...@litbit.com>> wrote:
> Gunnar you are not getting ahead of yourself - We the project are behind and with your help we can get up to speed and get out a release. I am committed to getting this release out as soon as I can. With help from you and other individuals we can do this. The vision is vast and the area is exciting (IoT!). It begins with iota but there is a lot more after that. I am looking forward in learning more about the Apache Way as are other committers with limited Apache experience.
> 
> I would like to get you access to the iota confluence pages and I would hope you could replicate the generic part of the framework you setup for Trafodian. Once a framework has been setup I and other r committers will begin to fill in the iota specific parts. I am sure you will be able to contribute in these specifics once you have some experience with iota. As a committer can I give you permission to edit the iota pages? Do we need to add you as an iota committer? How do we get you access?
> 
> I and Barbara Malta Gomes can work on a basic document that will walk users/developers through the process of installing iota on their PC so they can begin to experience iota and hopefully start building performers that they can contributed to the iota project. The document will explain how to install and build iota using SBT command-line style , it will explain how to write a basic performer and run it on their PC. 
> 
> I suggest we discuss and get clarity on what belongs on dev and what belongs on users. Here is a strawman proposal
> 1) Developers - installation, build, iota engine, and iota performers, explanations on how to write performers
> 2) Users - install iota and use orchestrations to build robust applications with no knowledge of Java/Scala/Akka. Just need to understand how to how to write an orchestration which is essential just a json object. [ Hint; great opportunity for someone to write a user friendly tool similar to Java Studio or IFTTT (If this then that) to generate and run iota orchestrations that are json objects - not too user friendly]
> Is this the Apache Way?
> 
> We should get involved in the emerging IoT mini conference in Miami - we should have a release done before that conference and an iota presentation ready.
> 
> Gunnar I want to fix  "Also, it'd be good to fix the link in the "Apache" row on the incubator page so that it works: http://incubator.apache.org/projects/iota.html <http://incubator.apache.org/projects/iota.html>”
> Not sure what you mean - is the link not working or it is pointing to the wrong place?
> 
> Thanks
> -Tony
> 
>> On Feb 5, 2017, at 11:13 AM, Gunnar Tapper <tapper.gunnar@gmail.com <ma...@gmail.com>> wrote:
>> 
>> Hi,
>> 
>> I might be getting ahead of myself on involvement but I thought I'd share a few lessons I learnt about Apache incubation... 
>> 
>> 1. The main focus of Apache is the community and the Apache Way. 
>> 
>> When you first get involved, it's a bit hard to understand this since you're likely used to drive product and product value. You do need an interesting project for people to get involved (what can be cooler that IoT!) but Apache cares more that we build a community, get releases out, and so on.
>> 
>> 2. Distribution list are everything
>> 
>> ALL (and I mean ALL) discussions and decisions need to happen on the iota mailing lists. These mailing lists ARE the record of the project and indicates activity.
>> 
>> Of course, you need Stack Overflow, Slack, and other things to build a community but they don't quite "count." 
>> 
>> Further, we need to ensure that both user and dev lists are active. The easiest way to think about user is to go "would a user benefit from this?" A good example is discussing how to install the product for documentation -- have that discussion on the user list since it allows people to find install instructions before the website has proper documentation.
>> 
>> 3. Release often
>> 
>> It takes a few releases to dot all the Is and cross all the Ts on releasing the Apache Way. Don't worry about quality in the beginning, worry about following the processes and getting passed on the legal stuff.
>> 
>> Next, move to a stable/bleeding edge model so that you can continue to release often. You'll find that the major Hadoop projects follow this model so that people can help testing without having to build the product and to ensure constant project activity. 
>> 
>> I recommend a scheduled train model every N weeks.
>> 
>> 4. Mentors have day jobs
>> 
>> The mentors' job is to help guide the incubator to graduation. GUIDE is the operating word here so don't expect hands-on help unless the mentors have time for hands-on. Further, mentors are often involved with several incubators.
>> 
>> 5. You have to excite people
>> 
>> People get involved when they think that a project is cool. It's very much a fashion thing in my opinion. For example, I'm getting involved in iota because I love the idea of IoT and want to be able to build IoT solutions. Plus, I think that I can help.
>> 
>> My point here is that you have to sell the project as much as you sell products developed on top of it. We need presentations, videos, Twitter, easy ways to get involved, and so on. 
>> 
>> 6. Lead with open source
>> 
>> Ensure that whatever solution you're building on top of iota relies on the fact that the required functions are put into iota and released so that the solution DEPENDS on iota release X. It's the normal pecking order: OS before database before middle ware before applications.
>> 
>> 7. You are an individual
>> 
>> You may be paid by a company but to Apache, you are an individual that expresses your opinions and makes your contributions.
>> 
>> This was very hard for me in the beginning because I was used to always communicate in we form. Now, I've learnt to use "I" when I am expressing what I think and "we" when I am referring to the project as a whole.
>> 
>> I hope this helps. 
>> 
>> -- 
>> Thanks,
>> 
>> Gunnar
>> If you think you can you can, if you think you can't you're right.
> 
> 
> 
> 
> -- 
> Thanks,
> 
> Gunnar
> If you think you can you can, if you think you can't you're right.
> 
> 
> 
> -- 
> Thanks,
> 
> Gunnar
> If you think you can you can, if you think you can't you're right.

Re: Graduation

[Gunnar Tapper <ta...@gmail.com>]

Hi Justin:

Have you had a chance to add me as an editor of the iota wiki pages? I just
checked and I don't have the necessary permissions.

My user ID is: gtapper

Tack,

Gunnar

On Sun, Feb 5, 2017 at 5:45 PM, Gunnar Tapper <ta...@gmail.com>
wrote:

> Hi Tony,
>
> As Justin states, I've not earned the status of committer yet. That comes
> with time. By getting involved, I am contributing, which means that I am an
> iota contributor. Contribution comes in many forms: presenting, using,
> testing, asking questions, coding, etc. We'll cover that in the iota
> Contributor's Guide.
>
> IMO, documentation should be separated on the wiki and in the source tree.
> Here's my rule-of-thumb:
>
> 1. Release-dependent documentation goes with the code since it needs to be
> versioned. Change this documentation as part of code checkin.
> 2. Contributor Guides, examples, project management stuff, etc. goes on
> the wiki. No versioned information is expected so the text has to handle
> situations such as "build like this in version 1; build like this in
> version 2."
>
> I also suggest a jira for "we need a user friendly tool similar to Java
> Studio or IFTTT" so that the idea doesn't get lost. I also suggest a wiki
> page that provides a list of get-your-feet-wet Jiras for people that want
> to get involved. Nothing like early success that you know others will find
> useful.
>
> So, let's start out with the contributor's guide. I'll set up a basic
> structure and then we can add in info on the basics: where is stuff, what's
> needed to build, how to build, how to run, and to test, and how to
> contribute new/modified function. After that, then I suggest that we try to
> work through a release ensuring that all requirements are met. Justin will
> be a great help here because he knows the ins and out of what's required.
>
> Thoughts?
>
> Thanks,
>
> Gunnar
>
> On Sun, Feb 5, 2017 at 1:03 PM, Tony Faustini <to...@litbit.com> wrote:
>
>> Gunnar you are not getting ahead of yourself - We the project are behind
>> and with your help we can get up to speed and get out a release. I am
>> committed to getting this release out as soon as I can. With help from you
>> and other individuals we can do this. The vision is vast and the area is
>> exciting (IoT!). It begins with iota but there is a lot more after that. I
>> am looking forward in learning more about the Apache Way as are other
>> committers with limited Apache experience.
>>
>> I would like to get you access to the iota confluence pages and I would
>> hope you could replicate the generic part of the framework you setup for
>> Trafodian. Once a framework has been setup I and other r committers will
>> begin to fill in the iota specific parts. I am sure you will be able to
>> contribute in these specifics once you have some experience with iota. As a
>> committer can I give you permission to edit the iota pages? Do we need to
>> add you as an iota committer? How do we get you access?
>>
>> I and Barbara Malta Gomes can work on a basic document that will walk
>> users/developers through the process of installing iota on their PC so they
>> can begin to experience iota and hopefully start building performers that
>> they can contributed to the iota project. The document will explain how to
>> install and build iota using SBT command-line style , it will explain how
>> to write a basic performer and run it on their PC.
>>
>> I suggest we discuss and get clarity on what belongs on dev and what
>> belongs on users. Here is a strawman proposal
>> 1) Developers - installation, build, iota engine, and iota performers,
>> explanations on how to write performers
>> 2) Users - install iota and use orchestrations to build robust
>> applications with no knowledge of Java/Scala/Akka. Just need to understand
>> how to how to write an orchestration which is essential just a json object.
>> [ Hint; great opportunity for someone to write a user friendly tool similar
>> to Java Studio or IFTTT (If this then that) to generate and run iota
>> orchestrations that are json objects - not too user friendly]
>> Is this the Apache Way?
>>
>> We should get involved in the emerging IoT mini conference in Miami - we
>> should have a release done before that conference and an iota presentation
>> ready.
>>
>> Gunnar I want to fix  "Also, it'd be good to fix the link in the "Apache"
>> row on the incubator page so that it works: http://incubator.apache
>> .org/projects/iota.html”
>> Not sure what you mean - is the link not working or it is pointing to the
>> wrong place?
>>
>> Thanks
>> -Tony
>>
>> On Feb 5, 2017, at 11:13 AM, Gunnar Tapper <ta...@gmail.com>
>> wrote:
>>
>> Hi,
>>
>> I might be getting ahead of myself on involvement but I thought I'd share
>> a few lessons I learnt about Apache incubation...
>>
>> 1. The main focus of Apache is the community and the Apache Way.
>>
>> When you first get involved, it's a bit hard to understand this since
>> you're likely used to drive product and product value. You do need an
>> interesting project for people to get involved (what can be cooler that
>> IoT!) but Apache cares more that we build a community, get releases out,
>> and so on.
>>
>> 2. Distribution list are everything
>>
>> ALL (and I mean ALL) discussions and decisions need to happen on the iota
>> mailing lists. These mailing lists ARE the record of the project and
>> indicates activity.
>>
>> Of course, you need Stack Overflow, Slack, and other things to build a
>> community but they don't quite "count."
>>
>> Further, we need to ensure that both user and dev lists are active. The
>> easiest way to think about user is to go "would a user benefit from this?"
>> A good example is discussing how to install the product for documentation
>> -- have that discussion on the user list since it allows people to find
>> install instructions before the website has proper documentation.
>>
>> 3. Release often
>>
>> It takes a few releases to dot all the Is and cross all the Ts on
>> releasing the Apache Way. Don't worry about quality in the beginning, worry
>> about following the processes and getting passed on the legal stuff.
>>
>> Next, move to a stable/bleeding edge model so that you can continue to
>> release often. You'll find that the major Hadoop projects follow this model
>> so that people can help testing without having to build the product and to
>> ensure constant project activity.
>>
>> I recommend a scheduled train model every N weeks.
>>
>> 4. Mentors have day jobs
>>
>> The mentors' job is to help guide the incubator to graduation. GUIDE is
>> the operating word here so don't expect hands-on help unless the mentors
>> have time for hands-on. Further, mentors are often involved with several
>> incubators.
>>
>> 5. You have to excite people
>>
>> People get involved when they think that a project is cool. It's very
>> much a fashion thing in my opinion. For example, I'm getting involved in
>> iota because I love the idea of IoT and want to be able to build IoT
>> solutions. Plus, I think that I can help.
>>
>> My point here is that you have to sell the project as much as you sell
>> products developed on top of it. We need presentations, videos, Twitter,
>> easy ways to get involved, and so on.
>>
>> 6. Lead with open source
>>
>> Ensure that whatever solution you're building on top of iota relies on
>> the fact that the required functions are put into iota and released so that
>> the solution DEPENDS on iota release X. It's the normal pecking order: OS
>> before database before middle ware before applications.
>>
>> 7. You are an individual
>>
>> You may be paid by a company but to Apache, you are an individual that
>> expresses your opinions and makes your contributions.
>>
>> This was very hard for me in the beginning because I was used to always
>> communicate in we form. Now, I've learnt to use "I" when I am expressing
>> what I think and "we" when I am referring to the project as a whole.
>>
>> I hope this helps.
>>
>> --
>> Thanks,
>>
>> Gunnar
>> *If you think you can you can, if you think you can't you're right.*
>>
>>
>>
>
>
> --
> Thanks,
>
> Gunnar
> *If you think you can you can, if you think you can't you're right.*
>



-- 
Thanks,

Gunnar
*If you think you can you can, if you think you can't you're right.*

Re: Graduation

[Gunnar Tapper <ta...@gmail.com>]

Hi Tony,

As Justin states, I've not earned the status of committer yet. That comes
with time. By getting involved, I am contributing, which means that I am an
iota contributor. Contribution comes in many forms: presenting, using,
testing, asking questions, coding, etc. We'll cover that in the iota
Contributor's Guide.

IMO, documentation should be separated on the wiki and in the source tree.
Here's my rule-of-thumb:

1. Release-dependent documentation goes with the code since it needs to be
versioned. Change this documentation as part of code checkin.
2. Contributor Guides, examples, project management stuff, etc. goes on the
wiki. No versioned information is expected so the text has to handle
situations such as "build like this in version 1; build like this in
version 2."

I also suggest a jira for "we need a user friendly tool similar to Java
Studio or IFTTT" so that the idea doesn't get lost. I also suggest a wiki
page that provides a list of get-your-feet-wet Jiras for people that want
to get involved. Nothing like early success that you know others will find
useful.

So, let's start out with the contributor's guide. I'll set up a basic
structure and then we can add in info on the basics: where is stuff, what's
needed to build, how to build, how to run, and to test, and how to
contribute new/modified function. After that, then I suggest that we try to
work through a release ensuring that all requirements are met. Justin will
be a great help here because he knows the ins and out of what's required.

Thoughts?

Thanks,

Gunnar

On Sun, Feb 5, 2017 at 1:03 PM, Tony Faustini <to...@litbit.com> wrote:

> Gunnar you are not getting ahead of yourself - We the project are behind
> and with your help we can get up to speed and get out a release. I am
> committed to getting this release out as soon as I can. With help from you
> and other individuals we can do this. The vision is vast and the area is
> exciting (IoT!). It begins with iota but there is a lot more after that. I
> am looking forward in learning more about the Apache Way as are other
> committers with limited Apache experience.
>
> I would like to get you access to the iota confluence pages and I would
> hope you could replicate the generic part of the framework you setup for
> Trafodian. Once a framework has been setup I and other r committers will
> begin to fill in the iota specific parts. I am sure you will be able to
> contribute in these specifics once you have some experience with iota. As a
> committer can I give you permission to edit the iota pages? Do we need to
> add you as an iota committer? How do we get you access?
>
> I and Barbara Malta Gomes can work on a basic document that will walk
> users/developers through the process of installing iota on their PC so they
> can begin to experience iota and hopefully start building performers that
> they can contributed to the iota project. The document will explain how to
> install and build iota using SBT command-line style , it will explain how
> to write a basic performer and run it on their PC.
>
> I suggest we discuss and get clarity on what belongs on dev and what
> belongs on users. Here is a strawman proposal
> 1) Developers - installation, build, iota engine, and iota performers,
> explanations on how to write performers
> 2) Users - install iota and use orchestrations to build robust
> applications with no knowledge of Java/Scala/Akka. Just need to understand
> how to how to write an orchestration which is essential just a json object.
> [ Hint; great opportunity for someone to write a user friendly tool similar
> to Java Studio or IFTTT (If this then that) to generate and run iota
> orchestrations that are json objects - not too user friendly]
> Is this the Apache Way?
>
> We should get involved in the emerging IoT mini conference in Miami - we
> should have a release done before that conference and an iota presentation
> ready.
>
> Gunnar I want to fix  "Also, it'd be good to fix the link in the "Apache"
> row on the incubator page so that it works: http://incubator.
> apache.org/projects/iota.html”
> Not sure what you mean - is the link not working or it is pointing to the
> wrong place?
>
> Thanks
> -Tony
>
> On Feb 5, 2017, at 11:13 AM, Gunnar Tapper <ta...@gmail.com>
> wrote:
>
> Hi,
>
> I might be getting ahead of myself on involvement but I thought I'd share
> a few lessons I learnt about Apache incubation...
>
> 1. The main focus of Apache is the community and the Apache Way.
>
> When you first get involved, it's a bit hard to understand this since
> you're likely used to drive product and product value. You do need an
> interesting project for people to get involved (what can be cooler that
> IoT!) but Apache cares more that we build a community, get releases out,
> and so on.
>
> 2. Distribution list are everything
>
> ALL (and I mean ALL) discussions and decisions need to happen on the iota
> mailing lists. These mailing lists ARE the record of the project and
> indicates activity.
>
> Of course, you need Stack Overflow, Slack, and other things to build a
> community but they don't quite "count."
>
> Further, we need to ensure that both user and dev lists are active. The
> easiest way to think about user is to go "would a user benefit from this?"
> A good example is discussing how to install the product for documentation
> -- have that discussion on the user list since it allows people to find
> install instructions before the website has proper documentation.
>
> 3. Release often
>
> It takes a few releases to dot all the Is and cross all the Ts on
> releasing the Apache Way. Don't worry about quality in the beginning, worry
> about following the processes and getting passed on the legal stuff.
>
> Next, move to a stable/bleeding edge model so that you can continue to
> release often. You'll find that the major Hadoop projects follow this model
> so that people can help testing without having to build the product and to
> ensure constant project activity.
>
> I recommend a scheduled train model every N weeks.
>
> 4. Mentors have day jobs
>
> The mentors' job is to help guide the incubator to graduation. GUIDE is
> the operating word here so don't expect hands-on help unless the mentors
> have time for hands-on. Further, mentors are often involved with several
> incubators.
>
> 5. You have to excite people
>
> People get involved when they think that a project is cool. It's very much
> a fashion thing in my opinion. For example, I'm getting involved in iota
> because I love the idea of IoT and want to be able to build IoT solutions.
> Plus, I think that I can help.
>
> My point here is that you have to sell the project as much as you sell
> products developed on top of it. We need presentations, videos, Twitter,
> easy ways to get involved, and so on.
>
> 6. Lead with open source
>
> Ensure that whatever solution you're building on top of iota relies on the
> fact that the required functions are put into iota and released so that the
> solution DEPENDS on iota release X. It's the normal pecking order: OS
> before database before middle ware before applications.
>
> 7. You are an individual
>
> You may be paid by a company but to Apache, you are an individual that
> expresses your opinions and makes your contributions.
>
> This was very hard for me in the beginning because I was used to always
> communicate in we form. Now, I've learnt to use "I" when I am expressing
> what I think and "we" when I am referring to the project as a whole.
>
> I hope this helps.
>
> --
> Thanks,
>
> Gunnar
> *If you think you can you can, if you think you can't you're right.*
>
>
>


-- 
Thanks,

Gunnar
*If you think you can you can, if you think you can't you're right.*

Re: Graduation

[Gunnar Tapper <ta...@gmail.com>]

Hi Justin,

It's good to see you involved with this project, too.

My Confluence ID is: gtapper

Thanks,

Gunnar

On Sun, Feb 5, 2017 at 1:22 PM, Justin Mclean <ju...@classsoftware.com>
wrote:

> HI,
>
> Welcome Gunnar, this project could do with some help, thanks for stepping
> up.
>
> I would like to get you access to the iota confluence pages
>
>
> Post your wiki user name here and I’ll sort it out.
>
>  Do we need to add you as an iota committer?
>
>
> One step at a time, as discussed before on this list the PPMC needs to
> vote committers in once they have shown merit.
>
> I suggest we discuss and get clarity on what belongs on dev and what
> belongs on users.
>
>
> Given there’s a small amount of traffic I’s suggest just using dev@ for
> now. You are of course welcome to do it another way, but if you do split it
> then just make are everyone is signed up to both list and users questions
> on users@ get answered.
>
> We should get involved in the emerging IoT mini conference in Miami - we
> should have a release done before that conference and an iota presentation
> ready.
>
>
> JFYI - The call for papers closes in about a week.
>
> Gunnar I want to fix  "Also, it'd be good to fix the link in the "Apache"
> row on the incubator page so that it works: http://incubator.
> apache.org/projects/iota.html”
>
>
> The text is repeated that’s all.
>
> Thanks,
> Justin
>



-- 
Thanks,

Gunnar
*If you think you can you can, if you think you can't you're right.*

Re: Graduation

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Justin, Is there a process that I need to use to fix the repeated text on the “Apache” row? Or do I just browse to the page and use the CMS tool to make those changes directly?

I fix it when I next update that page (unless another mentor does it first). It’s not a big issue.

Thanks,
Justin

Re: Graduation

[Tony Faustini <to...@litbit.com>]

Justin, Is there a process that I need to use to fix the repeated text on the “Apache” row? Or do I just browse to the page and use the CMS tool to make those changes directly?
Thanks
-Tony


> On Feb 5, 2017, at 12:22 PM, Justin Mclean <ju...@classsoftware.com> wrote:
> 
> HI,
> 
> Welcome Gunnar, this project could do with some help, thanks for stepping up.
> 
>> I would like to get you access to the iota confluence pages
> 
> Post your wiki user name here and I’ll sort it out.
> 
>>  Do we need to add you as an iota committer?
> 
> One step at a time, as discussed before on this list the PPMC needs to vote committers in once they have shown merit.
> 
>> I suggest we discuss and get clarity on what belongs on dev and what belongs on users.
> 
> Given there’s a small amount of traffic I’s suggest just using dev@ for now. You are of course welcome to do it another way, but if you do split it then just make are everyone is signed up to both list and users questions on users@ get answered.
> 
>> We should get involved in the emerging IoT mini conference in Miami - we should have a release done before that conference and an iota presentation ready.
> 
> JFYI - The call for papers closes in about a week.
> 
>> Gunnar I want to fix  "Also, it'd be good to fix the link in the "Apache" row on the incubator page so that it works: http://incubator.apache.org/projects/iota.html <http://incubator.apache.org/projects/iota.html>”
> 
> The text is repeated that’s all.
> 
> Thanks,
> Justin

Re: Graduation

[Justin Mclean <ju...@classsoftware.com>]

HI,

Welcome Gunnar, this project could do with some help, thanks for stepping up.

> I would like to get you access to the iota confluence pages

Post your wiki user name here and I’ll sort it out.

>  Do we need to add you as an iota committer?

One step at a time, as discussed before on this list the PPMC needs to vote committers in once they have shown merit.

> I suggest we discuss and get clarity on what belongs on dev and what belongs on users.

Given there’s a small amount of traffic I’s suggest just using dev@ for now. You are of course welcome to do it another way, but if you do split it then just make are everyone is signed up to both list and users questions on users@ get answered.

> We should get involved in the emerging IoT mini conference in Miami - we should have a release done before that conference and an iota presentation ready.

JFYI - The call for papers closes in about a week.

> Gunnar I want to fix  "Also, it'd be good to fix the link in the "Apache" row on the incubator page so that it works: http://incubator.apache.org/projects/iota.html <http://incubator.apache.org/projects/iota.html>”

The text is repeated that’s all.

Thanks,
Justin

Re: Graduation

[Tony Faustini <to...@litbit.com>]

Gunnar you are not getting ahead of yourself - We the project are behind and with your help we can get up to speed and get out a release. I am committed to getting this release out as soon as I can. With help from you and other individuals we can do this. The vision is vast and the area is exciting (IoT!). It begins with iota but there is a lot more after that. I am looking forward in learning more about the Apache Way as are other committers with limited Apache experience.

I would like to get you access to the iota confluence pages and I would hope you could replicate the generic part of the framework you setup for Trafodian. Once a framework has been setup I and other r committers will begin to fill in the iota specific parts. I am sure you will be able to contribute in these specifics once you have some experience with iota. As a committer can I give you permission to edit the iota pages? Do we need to add you as an iota committer? How do we get you access?

I and Barbara Malta Gomes can work on a basic document that will walk users/developers through the process of installing iota on their PC so they can begin to experience iota and hopefully start building performers that they can contributed to the iota project. The document will explain how to install and build iota using SBT command-line style , it will explain how to write a basic performer and run it on their PC. 

I suggest we discuss and get clarity on what belongs on dev and what belongs on users. Here is a strawman proposal
1) Developers - installation, build, iota engine, and iota performers, explanations on how to write performers
2) Users - install iota and use orchestrations to build robust applications with no knowledge of Java/Scala/Akka. Just need to understand how to how to write an orchestration which is essential just a json object. [ Hint; great opportunity for someone to write a user friendly tool similar to Java Studio or IFTTT (If this then that) to generate and run iota orchestrations that are json objects - not too user friendly]
Is this the Apache Way?

We should get involved in the emerging IoT mini conference in Miami - we should have a release done before that conference and an iota presentation ready.

Gunnar I want to fix  "Also, it'd be good to fix the link in the "Apache" row on the incubator page so that it works: http://incubator.apache.org/projects/iota.html <http://incubator.apache.org/projects/iota.html>”
Not sure what you mean - is the link not working or it is pointing to the wrong place?

Thanks
-Tony

> On Feb 5, 2017, at 11:13 AM, Gunnar Tapper <ta...@gmail.com> wrote:
> 
> Hi,
> 
> I might be getting ahead of myself on involvement but I thought I'd share a few lessons I learnt about Apache incubation... 
> 
> 1. The main focus of Apache is the community and the Apache Way. 
> 
> When you first get involved, it's a bit hard to understand this since you're likely used to drive product and product value. You do need an interesting project for people to get involved (what can be cooler that IoT!) but Apache cares more that we build a community, get releases out, and so on.
> 
> 2. Distribution list are everything
> 
> ALL (and I mean ALL) discussions and decisions need to happen on the iota mailing lists. These mailing lists ARE the record of the project and indicates activity.
> 
> Of course, you need Stack Overflow, Slack, and other things to build a community but they don't quite "count." 
> 
> Further, we need to ensure that both user and dev lists are active. The easiest way to think about user is to go "would a user benefit from this?" A good example is discussing how to install the product for documentation -- have that discussion on the user list since it allows people to find install instructions before the website has proper documentation.
> 
> 3. Release often
> 
> It takes a few releases to dot all the Is and cross all the Ts on releasing the Apache Way. Don't worry about quality in the beginning, worry about following the processes and getting passed on the legal stuff.
> 
> Next, move to a stable/bleeding edge model so that you can continue to release often. You'll find that the major Hadoop projects follow this model so that people can help testing without having to build the product and to ensure constant project activity. 
> 
> I recommend a scheduled train model every N weeks.
> 
> 4. Mentors have day jobs
> 
> The mentors' job is to help guide the incubator to graduation. GUIDE is the operating word here so don't expect hands-on help unless the mentors have time for hands-on. Further, mentors are often involved with several incubators.
> 
> 5. You have to excite people
> 
> People get involved when they think that a project is cool. It's very much a fashion thing in my opinion. For example, I'm getting involved in iota because I love the idea of IoT and want to be able to build IoT solutions. Plus, I think that I can help.
> 
> My point here is that you have to sell the project as much as you sell products developed on top of it. We need presentations, videos, Twitter, easy ways to get involved, and so on. 
> 
> 6. Lead with open source
> 
> Ensure that whatever solution you're building on top of iota relies on the fact that the required functions are put into iota and released so that the solution DEPENDS on iota release X. It's the normal pecking order: OS before database before middle ware before applications.
> 
> 7. You are an individual
> 
> You may be paid by a company but to Apache, you are an individual that expresses your opinions and makes your contributions.
> 
> This was very hard for me in the beginning because I was used to always communicate in we form. Now, I've learnt to use "I" when I am expressing what I think and "we" when I am referring to the project as a whole.
> 
> I hope this helps. 
> 
> -- 
> Thanks,
> 
> Gunnar
> If you think you can you can, if you think you can't you're right.