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 <[email protected]> wrote: > 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]> > 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.* > > > -- Thanks, Gunnar *If you think you can you can, if you think you can't you're right.*
