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