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 <[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.
