I'm suggesting that before we go to the proposal phase, people just start participating in SwellRT. Just do it. Let's see what you can all accomplish over there - let SwellRT see what they have to gain, and let Apache see how more vibrant and active SwellRT is as a community. Then it will be a no-brainer for Apache to accept SwellRT.
Upayavira On Mon, 10 Oct 2016, at 10:10 PM, Adam John wrote: > Sorry to have missed you, Thomas. > > "Cant a date be set, a vote be taken, then either import SwellRT or not?" > According to Upayavira there should be a proposal. > > This is what I've found: http://incubator.apache.org/guides/proposal.html > Although this seems more targeted to new projects. > > So the process would be: > (1) Create a proposal > (2) Submit it to the group via email > (3) Vote > > I've created this working document > <https://docs.google.com/document/d/1jhPRR9juJAhBBZ9qjYI5KxlaHSz-IJJdPQ6_3puwWBQ/edit?usp=sharing> > to get us started - but not sure if the template at the link above is > suitable. > > Talk soon! > > AJ > > Adam John > (914) 623-8433 > Google+ <http://google.com/+AdamJohn1> | LinkedIn > <http://mradamjohn.com/> > > On Mon, Oct 10, 2016 at 5:00 PM, Thomas Wrobel <darkfl...@gmail.com> > wrote: > > > I am sorry I didn't make the meeting, glade to see it was productive. > > However, I am curious though why there is questions still as to if > > SwellRT should be merged with wave. > > > > Wave development at apache is nearly dead. > > Doing nothing and it will have to retire. No one has proposed a 3rd > > option that I am aware of. > > So in terms of community engagement, not seeing a downside. > > > > If theres technical downsides, thats another mater. But not aware > > anyones raised any yet. > > From what I have seen possibly my only concern is the API to > > communicate to the server is just in javascript - we would > > eventually need alternatives if we want to allow native iOS and > > Android clients. > > > > > > "activity similar to this starts brewing and > > then it all dies down in a few months" > > > > > > True. Seen it many times. > > Maybe too much discussion with too little actual discussions resulting > > in anything changing. > > Cant a date be set, a vote be taken, then either import SwellRT or not? > > > > > > > > -- > > http://lostagain.nl <-- our company site. > > http://fanficmaker.com <-- our, really,really, bad story generator. > > > > > > On 6 October 2016 at 18:21, Pablo Ojanguren <pablo...@gmail.com> wrote: > > > Thanks Adam for clarifying the questions. > > > > > > Also I agree with Upayavira, the primary discussion it might be more > > about > > > "ideas" and the community's "engagement" with them. After that, tech > > > aspects would come. > > > > > > So, in this regard I would like to share some thoughts about SwellRT as a > > > product... > > > > > > a) Where SwellRT fit in the market? Competitors? > > > > > > SwellRT current vision is closer to products like Firebase, Meteor and > > > Realm. > > > They are new breed of frameworks/platforms to write apps. They provide as > > > key feature, real-time data storage with simple document-based data > > models. > > > Their aim is to simplify and speed up web/app development. And of course, > > > they allow to build real-time collaboration features easily. > > > > > > Of course, these projects are matured, but they still have pros and cons. > > > What it seems clear to me is the trend: to develop heavier apps/webapps > > > (because nowadays devices have a lot of computing power and it means just > > > coding for one system) and lighter backends providing common "services" > > > (notifications, storage, auth...). > > > > > > > > > > > > b) What Wave/SwellRT's tech could offer in this market as innovation? > > > Wave/SwellRT could compete with features like: > > > > > > - Open Source and JVM world: I guess there is still a part of the world > > > happy to see a Java friendly framework, despite it works for Web (but > > > hopefully for android/iOS). > > > > > > - Simpler API: with sugar syntax, for example, in SwellRT we are working > > in > > > a JS syntax just based in mutable objects. Also with API concepts easy to > > > understand: objects and participants. > > > > > > - Full-featured collaborative writing: Wave was designed for text > > editing, > > > whereas these new frameworks are focused in JSON. For example, > > annotations > > > is a cool feature not easy to provide I guess. Also the Wave's text > > editor > > > is very good yet. > > > > > > - Federation: it is the hardest selling point for developers in general > > > because it doesn't provide benefits in the short term. However, it is the > > > entrance to innovative things like cross-app interoperability, organic > > > scalability... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2016-10-05 23:47 GMT+02:00 Upayavira <u...@odoko.co.uk>: > > > > > >> I want to see a proposal regarding importing SwellRT that gives me > > >> confidence that bringing SwellRT into Wave will actually lead to an > > >> active project. > > >> > > >> A way this could be achieved *before* bringing SwellRT would be if > > >> everyone who is interested in contributing headed over to SwellRT, and > > >> started contributing over there. Then, we'd be bringing both code and > > >> community into Apache, which would give me far more confidence than just > > >> importing code but with no confidence that anyone is actually going to > > >> do anything with it. > > >> > > >> Upayavira > > >> > > >> On Wed, 5 Oct 2016, at 10:03 PM, Adam John wrote: > > >> > Pablo, a lot of great information in this slide deck. I hope others > > have > > >> > a > > >> > chance to review as well. Outstanding work. > > >> > > > >> > Price, very thoughtful responses. I agree with the overall > > conclusion - > > >> > SwellRT should be brought into Wave. > > >> > > > >> > I like the idea of moving the SwellRT fork in to replace the current > > >> > branch > > >> > of Wave development because it moves the project reasonably forward > > and > > >> > makes sense overall. It does not seem anything current would be lost > > in > > >> > that move. It seems like we have everything to gain. However, there > > >> > might > > >> > be work in progress that is affected. > > >> > > > >> > It would be great if contributors on the project took a look and > > shared > > >> > some thoughts. > > >> > > > >> > Q3) For current contributors; are you in favor of bringing the fork > > home? > > >> > > > >> > - > > >> > Great attendance at our last meeting, and familiar ground was covered. > > >> > (agenda > > >> > and notes > > >> > <https://docs.google.com/document/d/11j_ > > WQGYAtDlN8Wqx8jJglPpw6tJznvMGf > > >> dLOvQu96i0/edit>) > > >> > We're largely covering the next steps in recent emails. > > >> > > > >> > If the group agrees, that we should bring SwellRT into Apache Wave, > > then > > >> > there needs to be a proposal drafted. > > >> > > > >> > Q4) Does anyone have interest, experience or desire to help with this > > >> > task? We do not expect to start until after the next meeting. > > >> > > > >> > - > > >> > Perhaps 2-3 weeks is time enough to consider the questions posed? > > >> > I'd like to plan our next steps; > > >> > I suggest *10/26 as the next discussion* - based on consensus in the > > list > > >> > of course. > > >> > > > >> > The goal of the next meeting will be to provide a chance to address > > any > > >> > questions regarding bringing the projects together. Perhaps this > > could > > >> > be > > >> > a technically deeper discussion. > > >> > > > >> > Q5) Does anyone have interest in a standing co-work session? > > Especially > > >> > important would be current contributors. I think this could be a good > > >> > way > > >> > for some on the list that have stalled or reached impasse to begin to > > >> > make > > >> > progress in helping out. > > >> > > > >> > Thanks, everyone for your work and efforts. I believe that if each > > of us > > >> > does just a little bit over the next few weeks we will continue to see > > >> > the > > >> > progress we need in this project. > > >> > > > >> > Adam John > > >> > (914) 623-8433 > > >> > Google+ <http://google.com/+AdamJohn1> | LinkedIn > > >> > <http://mradamjohn.com/> > > >> > > > >> > On Wed, Oct 5, 2016 at 12:34 PM, Pablo Ojanguren <pablo...@gmail.com> > > >> > wrote: > > >> > > > >> > > Thanks for your answer Price, > > >> > > > > >> > > I guess we should not delay this discussion... > > >> > > > > >> > > I'd happy to run another call if you think it can move things > > forward. > > >> > > > > >> > > > > >> > > > > >> > > 2016-10-01 18:40 GMT+02:00 Price Clark <gpwcl...@gmail.com>: > > >> > > > > >> > > > Pablo, thanks for the presentation. > > >> > > > > > >> > > > While my qualifications to answer this are 0 getting to listen to > > >> > > > Upayavira talk this week (the last Apache mentor if I'm not > > mistaken) > > >> > > make > > >> > > > me feel the answers to 1 and 2 are easy to answer. > > >> > > > > > >> > > > 1.) Upayavira communicated very fervently that there just isn't > > >> enough > > >> > > > oomph in wave's development. Every year around the time that the > > >> > > retirement > > >> > > > conversation is brought up, activity similar to this starts > > brewing > > >> and > > >> > > > then it all dies down in a few months. From this perspective "Does > > >> > > SwellRT > > >> > > > tackle current Wave problems?" The answer is unequivocally yes, > > >> SwellRT > > >> > > is > > >> > > > a more actively maintained fork of Wave and given the > > slowing/slowed > > >> pace > > >> > > > of Wave *a merge with SwellRT is likely the only way to save this > > >> > > project*. > > >> > > > > > >> > > > 2.) I would also like to bring up another point Upayavira made, > > >> > > > "Communities are built around good ideas and bad code." Running > > with > > >> > > that I > > >> > > > thing that good ideas attract tinkerers and 'people with ideas' > > that > > >> > > could > > >> > > > eventually become 'contributors with ideas'. In some senses > > SwellRT > > >> > > > splinters Apache Wave in a way that developers on this mailing > > list > > >> have > > >> > > > been alluding to for a while. The client side code is not well > > >> understood > > >> > > > and is definitely in the way of the server. SwellRT has a more > > >> general > > >> > > goal > > >> > > > of supplying a server that is capable of powering a front-end like > > >> the > > >> > > > original vision of google wave. This means that merging with > > SwellRT > > >> > > would > > >> > > > force a separation of the client and server and allow for people > > with > > >> > > > interests in either a front or back end to work in tandem. This > > seems > > >> > > like > > >> > > > an ingenious way to attract more people; anyone with an interest > > in > > >> the > > >> > > > backend technology OR a way to use said technology in an > > application > > >> > > could > > >> > > > be a potential contributor. Unless I'm mistaken it seems like > > SwellRT > > >> > > > offers a set of features that could be classified as a superset of > > >> Wave's > > >> > > > features. So, it seems like most or all of SwellRT would be at > > home > > >> in > > >> > > > Wave. Pablo also reasonably stated that he'd prefer to work in one > > >> > > project. > > >> > > > > > >> > > > As for me, as soon as a direction is clear I would love to talk to > > >> > > > someone actively maintaining/writing code so I can help them > > >> contribute > > >> > > to > > >> > > > whichever code survives in whatever way possible. > > >> > > > > > >> > > > > >> > >
