Hi Gunnar please try again I added you. Please verify.
-Tony
> On Feb 6, 2017, at 10:17 PM, Gunnar Tapper <[email protected]> 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 <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>> 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.
