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