Hi all I think it is a good idea, to write these blogs as proposed and also to revisit our homepage as suggested. I can definitivly help writing the blogs, but I would be happy, if someone would like to jump in for actually proposing/thinking on the blog's agenda/content... This would be a great help due to my limited time...
OK? Other ideas? J Anatole ---------- Forwarded message --------- Von: David Blevins <[email protected]> Date: Fr., 26. Apr. 2019 um 02:19 Uhr Subject: Re: Podling health - Github Accounts linked to active committers To: <[email protected]> > On Apr 23, 2019, at 4:34 AM, Werner Keil <[email protected]> wrote: > > Some especially the likes of David Blevins are probably more "representational figures" because except TomEE (also doubt it, he's mostly into management now) I am sure he does no coding any more now. He definitely spends most his time managing, but still codes on weekends and evenings. :) According to github I got 127 commits in February and 109 in March. We do have some proprietary obligations, so I try to fall on that sword and give the open source time to everyone else. On the topic of Tamaya and activity. It is very unlikely I'll have any time. I'm very happy if someone wants to step up as mentor/champion. On things that can be done to raise the profile of the project and get more troops for graduation, I strongly recommend two or three very small and code-focused blog posts and submit them for inclusion here: - https://microprofile.io/blog/ Time them out by say 2 weeks. They'll get on microprofile.io and be retweeted by @MicroProfileIO which has 3k followers. I took a look a the "Tamaya in 5 minutes" page. It isn't really a getting started in five minutes kind of page. It's more an "essential resources" kind of index, which if you click any of the links on the page will be way more than five minutes. It also makes another mistake I used to and still make a lot, assuming the audience already knows MicroProfile Config or Tamaya's APIs. That quick start is only usable by the most experienced person. I recommend taking this content and putting it on the front page so people see code the second they visit: - http://tamaya.incubator.apache.org/documentation/quickstart.html I'd flip the order of that first section so it went like this: - short description of Tamaya's goals and why it's unique - the maven coordinates - Add/define your configuration data (with a example configuration data referenced in the subsequent example code) - Start Coding (the code block you have there) That's good enough for now. You can put the six boxes under that. I notice the link to the "as a standard" box is a 404. In the future, I think this page is on the right track, especially with the text to code ratio of "Configuration Auto-Discovery and Builders". If you had 4 or 5 of those on the Tamaya front page after the quickstart, that'd be awesome. - http://tamaya.incubator.apache.org/features.html I hope any of this is helpful. It's super hard to see your own project like others who are seeing it for the first time. So I've tried to be helpful as I can and give first impressions. Feel free to chuck them all in the garbage, it's ok :) If you are going to push some content through MicroProfile.io, I might suggest reconciling whether you want to put the Tamaya API for code on the front page or the MicroProfile Config API for code on the front page. There's a bit of a project decision that has to be made here. Is the goal to compete with MicroProfile Config or embrace it? Right now it looks competitive and the link to "as a standard" being a 404 doesn't give a better perspective. I think it will be an increasingly uphill battle to compete against the MicroProfile Config API, so where they overlap, I would probably use the MicroProfile Config API. I suspect there might be a ton of coding to achieve the following, but this would be a great thing to read in the front-page "Worlds most complete MicroProfile Config implementation with a rich set of extensions any organization needs." Show people how to start with the MicroProfile Config API and then go 10 steps further with all the unique ideas in the project that existed before MicroProfile Config. They would need to be recast "on top of" MicroProfile Config, which is where the coding might come in. But if you can make that happen, I smell overnight success. There's a rich set of real-world tested features in this, that's the advantage. It's also a disadvantage as all of them were coded before MicroProfile Config, so unless they are adapted people can't use them and still use MicroProfile Config APIs. People are silently being asked to chose. Eliminate that from the equation and you'll jump 10 steps forward. -David -- *Anatole Tresch* PPMC Member Apache Tamaya JCP Star Spec Lead *Switzerland, Europe Zurich, GMT+1* *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> * *Twitter: @atsticks, @tamayaconf*
