Github user asfgit closed the pull request at:
https://github.com/apache/incubator-wave-android/pull/1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the f
GitHub user calebamiles opened a pull request:
https://github.com/apache/incubator-wave-android/pull/1
Fix documentation link typo
https://incubator.apacehhe.org -> https://incubator.apache.org
You can merge this pull request into a Git repository by running:
$ git pull ht
> On Feb. 7, 2016, 1:54 p.m., Evan Hughes wrote:
> > To build on what yuri said on the github.
> >
> > Having the example in the source files isnt end of the world as this is
> > where the documentation is located. When the documentation is expanded apon
> >
eb. 7, 2016, 1:02 p.m.)
>
>
> Review request for wave.
>
>
> Repository: wave
>
>
> Description
> ---
>
> PST: add example code and some documentation
>
>
> Diffs
> -
>
> pst/README.md PRE-CREATION
> pst/example/.gitignore PRE-CREA
> On Feb. 7, 2016, 1:54 nachm., Evan Hughes wrote:
> > To build on what yuri said on the github.
> >
> > Having the example in the source files isnt end of the world as this is
> > where the documentation is located. When the documentation is expanded apon
>
the source files isnt end of the world as this is where
the documentation is located. When the documentation is expanded apon and
include in the docs repo then I agree but I dont see a problem with it being
included here atm.
In other news, do you mind squashing your commits so we only need to
example code and some documentation
Diffs
-
pst/README.md PRE-CREATION
pst/example/.gitignore PRE-CREATION
pst/example/beans.st PRE-CREATION
pst/example/example.proto PRE-CREATION
pst/example/example.st PRE-CREATION
Diff: https://reviews.apache.org/r/43301/diff/
Testing
GitHub user wisebaldone opened a pull request:
https://github.com/apache/incubator-wave-docs/pull/8
Added api documentation
added missing api section from the old waveprotocol website.
You can merge this pull request into a Git repository by running:
$ git pull https
ld we always end up working on a
major-release-numbered branch?
The developer-docs and protocol-docs are now looking great! It would
be nice to get these on the website soon.
Ali
On 27 June 2015 at 11:32, Evan Hughes wrote:
> two pull requests on the documentation git repository, mos
Repository: incubator-wave-docs
Updated Branches:
refs/heads/0.4 608603b20 -> e14218b4a
Addition of whitepapers stored in the Main repository into the protocol
documentation
Project: http://git-wip-us.apache.org/repos/asf/incubator-wave-docs/repo
Commit:
http://git-wip-us.apache.org/re
two pull requests on the documentation git repository, mostly just
transferring from the confluence to the repository.
Sounds good to me.
On Sun, May 17, 2015 at 1:40 AM Ali Lown wrote:
> Okay. I merged and pushed those changes.
>
> Should I be squashing the commits into a single one before pushing?
> Does anyone have any preferences on this/other parts of git -
> branching and tagging documenta
Okay. I merged and pushed those changes.
Should I be squashing the commits into a single one before pushing?
Does anyone have any preferences on this/other parts of git -
branching and tagging documentation?
I was assuming we have something along the lines of a branch of docs
for each major
to do at some point, as you are likely to
> >> continue making not-insignificant changes to this repo.
> >>
> >> @Yuri/Others: How do we want to handle PR reviews?
> >> I propose doing it the same way as on review-board, of leaving
> >> comments on the sy
omments on the system as appropriate.
>>> Do we want to wait for multiple committers to say LGTM?
>>>
>>> I propose that at the moment, whilst the documentation repo is being
>>> built up, that we just commit the PRs after looking over them for
>>> sanity
iews?
>> I propose doing it the same way as on review-board, of leaving
>> comments on the system as appropriate.
>> Do we want to wait for multiple committers to say LGTM?
>>
>> I propose that at the moment, whilst the documentation repo is being
>> built up, that
Changed File Structure => Api, Developer, Manual, Protocol, Documentation.
Api: All docs relating to the robot/gadgets api
Developer: Setting up server, guides on adding to development
Manual: User manual to be provided with the official client
Protocol: technical resources defining the w
The "documentation" project has been started, has minimum information to be
able to be built on a linux operating system
Project: http://git-wip-us.apache.org/repos/asf/incubator-wave-docs/repo
Commit:
http://git-wip-us.apache.org/repos/asf/incubator-wave-docs/commit/c6196d00
Tree:
to this repo.
>
> @Yuri/Others: How do we want to handle PR reviews?
> I propose doing it the same way as on review-board, of leaving
> comments on the system as appropriate.
> Do we want to wait for multiple committers to say LGTM?
>
> I propose that at the moment, whilst the docum
way as on review-board, of leaving
comments on the system as appropriate.
Do we want to wait for multiple committers to say LGTM?
I propose that at the moment, whilst the documentation repo is being
built up, that we just commit the PRs after looking over them for
sanity, and then lock it down a
For Pull request
On 9 May 2015 at 17:12, Evan Hughes wrote:
> I believe we should split the docs into:
>
> Documentation => Documents how to build the documentation and how to use
> sphinx + ReST (mostly just an example and to help ease the transition)
> manual
I believe we should split the docs into:
Documentation => Documents how to build the documentation and how to use
sphinx + ReST (mostly just an example and to help ease the transition)
manual => The user manual provided with the client (How to
make a wave, .)
dev
kdown but is more powerful) thanks to Python docs making
use of it.
Can we find any other volunteers for moving the docs out of
confluence, as there is quite a lot to do?
Ali
On 1 May 2015 at 04:03, Evan Hughes wrote:
> I think sphinx would be a better option than jekyll for the documentati
I think sphinx would be a better option than jekyll for the documentation,
it does use restructured text instead of markdown but is more extensible
and can easily produce a pdf format compared to markdown. Gonna spin up my
own repo and see how it is, been looking at the syntax and it isn't
ite off of the cms but not sure if
> it should be in same repository. Ill look into jekyll for the documentation
> but theres also other build systems which might be better for us aka html
> and pdf export.
>
> Go ahead with the repository for the documentation and well go from the
I ll submit the new RC today.
On Wed, Apr 29, 2015 at 2:54 AM Evan Hughes wrote:
> I like the idea of also moving the website off of the cms but not sure if
> it should be in same repository. Ill look into jekyll for the documentation
> but theres also other build systems which might
I like the idea of also moving the website off of the cms but not sure if
it should be in same repository. Ill look into jekyll for the documentation
but theres also other build systems which might be better for us aka html
and pdf export.
Go ahead with the repository for the documentation and
the existing confluence system. So I would have
> though that improving the documentation is something people would be
> more likely to do afterwards.
>
> I agree that opening some tickets where the documentation could be
> improved does help highlight the problem, but it doesn't ma
Yuri,
I think the main reason to move is to make it easier for people to
make changes, over the existing confluence system. So I would have
though that improving the documentation is something people would be
more likely to do afterwards.
I agree that opening some tickets where the documentation
Maybe it would be better to move in small steps. Like to go over current
documentation and open tickets with requests for improvements wherever
something is missing or not clear.
On Tue, Apr 28, 2015 at 5:33 PM Ali Lown wrote:
> Well, doesn't look like anybody else has much opinion.
>
ed in leading the migration effort?
>>
>> Ali
>>
>> On 24 April 2015 at 05:59, Evan Hughes wrote:
>> > woops, my bad
>> >
>> >
>> > This is a proposal for the storage of documentation to be moved to a git
>> > repository inst
d
> >
> >
> > This is a proposal for the storage of documentation to be moved to a git
> > repository instead of on confluence and leave confluence as a place for
> > other technical documents used by developers.
> >
> > *Confluence:*
> > *The issu
changing them.
Would you be interested in leading the migration effort?
Ali
On 24 April 2015 at 05:59, Evan Hughes wrote:
> woops, my bad
>
>
> This is a proposal for the storage of documentation to be moved to a git
> repository instead of on confluence and leave confluence
woops, my bad
This is a proposal for the storage of documentation to be moved to a git
repository instead of on confluence and leave confluence as a place for
other technical documents used by developers.
*Confluence:*
*The issues:*
- contributors must ask for permission from the
This is a proposal for
TL;DR
Ahh, and no uploader for MacOS
On Fri, Aug 1, 2014 at 1:12 PM, Yuri Z wrote:
> Hi Evan
> We have some documentation, mainly in various README files which are part
> of the source and the Wiki.
> Usually the README files are more up to date. I think it could be nice to
> go
Hi Evan
We have some documentation, mainly in various README files which are part
of the source and the Wiki.
Usually the README files are more up to date. I think it could be nice to
go over the README files and Wiki and ensure that all the information is
consistent and up to date.
On Fri, Aug
where would be the best place to start with helping grow the documentation?
Very useful
-Original Message-
From: Pablo Ojanguren [mailto:pablo...@gmail.com]
Sent: Wednesday, February 19, 2014 5:00 PM
To: wave-dev@incubator.apache.org
Subject: Re: Contributing WIAB documentation
Done! I hope you find it useful.
Thank you.
2014-02-18 17:08 GMT+01:00 Ali Lown
Done! I hope you find it useful.
Thank you.
2014-02-18 17:08 GMT+01:00 Ali Lown :
> Pablo,
>
> You should have permissions to make changes now.
>
> Ali
>
> On 18 February 2014 15:59, Pablo Ojanguren wrote:
> > Ops, I don't have permissions yet. My username is "pablojan".
> >
> > Thank you!
>
Pablo,
You should have permissions to make changes now.
Ali
On 18 February 2014 15:59, Pablo Ojanguren wrote:
> Ops, I don't have permissions yet. My username is "pablojan".
>
> Thank you!
>
>
> 2014-02-18 16:55 GMT+01:00 Yuri Z :
>
>> Yeah, Thanks Pablo!
>>
>>
>> On Tue, Feb 18, 2014 at 5:32
Ops, I don't have permissions yet. My username is "pablojan".
Thank you!
2014-02-18 16:55 GMT+01:00 Yuri Z :
> Yeah, Thanks Pablo!
>
>
> On Tue, Feb 18, 2014 at 5:32 PM, Ali Lown wrote:
>
> > Pablo,
> >
> > This looks great!
> >
> > Please do add it to the wiki (merge it in with the existing
Yeah, Thanks Pablo!
On Tue, Feb 18, 2014 at 5:32 PM, Ali Lown wrote:
> Pablo,
>
> This looks great!
>
> Please do add it to the wiki (merge it in with the existing stuff in
> Contributing/Wave-in-a-box Design).
> https://cwiki.apache.org/confluence/display/WAVE/Wave+In+a+Box+Design
>
> If you n
Pablo,
This looks great!
Please do add it to the wiki (merge it in with the existing stuff in
Contributing/Wave-in-a-box Design).
https://cwiki.apache.org/confluence/display/WAVE/Wave+In+a+Box+Design
If you need permissions to edit the wiki, let me know your username
and I will grant them.
Than
t,
> >
> >John Blossom
> >
> >email: jblos...@gmail.com
> >phone: 203.293.8511
> >google+: https://google.com/+JohnBlossom
> >
> >
> >On Thu, May 23, 2013 at 4:33 PM, Justin Beals
> >wrote:
> >
> >> Hi all,
> >>
> >
;>
>> I've been lurking on this list for a little bit and am really glad to
>>see
>> some activity. I thought I would chime in. I am interested in
>> contributing to the design and documentation tasks that may arise for
>>the
>> Apache Wave project. I have
ought I would chime in. I am interested in
> contributing to the design and documentation tasks that may arise for the
> Apache Wave project. I have UXD & User experience.
>
> My interest in Wave is as a replacement to the typical 'forum' or
> 'discussion board
Hey Justin,
Great to hear you're interested, not too sure on what design work needs to
be done, but we're currently moving our documentation over from gcode and
waveprotocol.org to the apache wave confluence wiki. You need to contact
Michael (michael.macfad...@gmail.com) to get acces
Hi all,
I've been lurking on this list for a little bit and am really glad to see
some activity. I thought I would chime in. I am interested in
contributing to the design and documentation tasks that may arise for the
Apache Wave project. I have UXD & User experience.
My interest i
uld ask Michael since he
> seems to be the only person with access currently.
>
> On 15 March 2013 23:33, Angus Turner wrote:
> > Hi all,
> > I once again have time off, and i'm planning on spending a couple of days
> > trying to clean up Waves documentation and mov
Ali
PS. Regarding permissions to edit pages, I would ask Michael since he
seems to be the only person with access currently.
On 15 March 2013 23:33, Angus Turner wrote:
> Hi all,
> I once again have time off, and i'm planning on spending a couple of days
> trying to clean up Waves d
clean up Waves documentation and moving it over to Apache.
> What kind of things are people looking for
> I'm thinking at least:
> -Mac OSX, Windows and Linux (Ubuntu?) build and run instructions
> -Something on common configurations (nginx is the first that comes to
> mind..)
>
with it!
> Though I couldn't fail to notice that a lot of things are not very
> well documented. (no offence intended!)
> So I wrote some of the things I learned down. Maybe you can use it
> for some form of official/unofficial documentation or at least link
> to it somewhere.
own. Maybe you can use it
for some form of official/unofficial documentation or at least link
to it somewhere. I'm also still writing a longer piece about how to
install and configure it with SSL.
Here is what I've written down so far:
http://bashvi.tumblr.com/post/41642537267/some-apache
Niclas,
It is nice to know a company is trying to work with Wave.
Unfortunately, there is no longer any single point of documentation
completely relevant to WIAB ATM (that I know of).
The best documentation is the WIAB source code (if you are comfortable
reading it).
If you are looking to build
concerning these matters, but
it's really hard knowing which documentation is still relevant and which is
obsolete.
One source is
https://cwiki.apache.org/confluence/display/WAVE/Wave+API+documentation but
not all seems to be up-to-date.
My questions are: Where do I find relevant and (as com
Hi,
I was wondering if I can find any documentation, design doc or explanation
about the undo manager in the wave editor. I am particularly interested in
how the undo manager interacts with server operations, and how it performs
undo-ing of client operations after applying server operations
le to get to the actual extension API references, only the
> overviews. Where is the rest of the documentation?
>
> --Zachary “Gamer_Z.” Yaro
>
>
> On Sun, Jul 10, 2011 at 00:06, Soren Lassen wrote:
>
>> Google copied the Wave API documentation to waveprotocol.org last year:
I am not able to get to the actual extension API references, only the
overviews. Where is the rest of the documentation?
--Zachary “Gamer_Z.” Yaro
On Sun, Jul 10, 2011 at 00:06, Soren Lassen wrote:
> Google copied the Wave API documentation to waveprotocol.org last year:
>
&
Google copied the Wave API documentation to waveprotocol.org last year:
https://sites.google.com/a/waveprotocol.org/wave-protocol/wave-apis
It's all there and belongs to Apache Wave now. (There are some broken
links in the waveprotocol.org copy but that should be easy to fix.)
With rega
Any update on this? It seems like the API documentation is already
deprecated, and one day it can be just taken down, while there's a lot of
valuable and relevant information for the WIAB project. Can someone from the
Googlers to check if some of the Google Wave API documentation can be
Are you referring to the help center pages
(http://www.google.com/support/wave/)?
On Fri, Apr 1, 2011 at 8:35 PM, Yuri Z wrote:
> Hello
> Does anyone knows if the Google Wave end user documentation (Help, guides
> etc..) can be open sourced or Google retained rights on it?
> Yuri
>
Hello
Does anyone knows if the Google Wave end user documentation (Help, guides
etc..) can be open sourced or Google retained rights on it?
Yuri
Hi there,
I'm maybe a bit out of date on current C/S implementation, so sorry if II
state something wrong here but for what I remember for wave-vs
implementation on this...
Theory for Client Side is to cache you local updates sending one by one to
server while accept WaveletUpdates coming from Se
>
> There's still one thing that's fuzzy in the spec concerning submitted
> deltas and the subsequent delta updates. When a client submits a delta, the
> way it transforms wavelet updates is different depending on whether or not
> the update was applied before or after the submitted delta. If the c
On Mon, Dec 13, 2010 at 5:34 PM, Torben Weis wrote:
> Hi Tad,
>
> this problem was on my mind for a long time.
> Caching updates is not the ideal solution for interactivity and
> collaboration, because updates are unnecessarily delayed.
>
> What a client really needs is a way to detect its own de
Hi Tad,
this problem was on my mind for a long time.
Caching updates is not the ideal solution for interactivity and
collaboration, because updates are unnecessarily delayed.
What a client really needs is a way to detect its own delta when receiving
it as a wavelet update.
Soren told me how to d
abbo...@gmail.com
> > Wave: nat.abbo...@wavewatchers.org
> > Twitter: @natabbotts (http://twitter.com/natabbotts)
> >
> >
> >
> > On Mon, Dec 13, 2010 at 03:56, Alex North wrote:
> >
> > > Thanks for offering to lead improvements to the docs, Nathana
I'd be
> > enthusiastic to advise and provide knowledge to fill the gaps for anyone
> > building some documentation. For the items you mentioned:
> >
> > - OT: we are very aware the documentation is lacking. The sad fact is
> that
> > the algorithms we ended up wi
e docs, Nathanael. I'd be
> enthusiastic to advise and provide knowledge to fill the gaps for anyone
> building some documentation. For the items you mentioned:
>
> - OT: we are very aware the documentation is lacking. The sad fact is that
> the algorithms we ended up with a
Thanks for offering to lead improvements to the docs, Nathanael. I'd be
enthusiastic to advise and provide knowledge to fill the gaps for anyone
building some documentation. For the items you mentioned:
- OT: we are very aware the documentation is lacking. The sad fact is that
the algorith
Hi to all, just joined the list :)
I'll help with the documentation to begin an implementation from scratch,
maybe not as main writer but I'll help to review everything and provide all
my experience...
Probably as I have already port wave platform to other language,
(c#.net), this
"The dogfood step makes sense - if the wave documentation can't be maintained
in a wave, what's the point!"
Surely the point is for wiab to reach a point where it can be used for
the documentation?
If, however, we wait for that before any docs, we might never get to
that stage
ode requires good planning and good documentation, and so far, I
>haven't seen much planning or documentation regarding a couple of very
>important things:
>
> - Operational Transformation
> - OT is one of the fundamental backends of the Wave Protocol, but the
> O
Hello
On Sat, Dec 11, 2010 at 13:19, Hugh Dougherty wrote:
> I'm an editor with some technical skill. I'll help wherever needed. Just
> let
> me know what I need to do.
I will also be happy to help with the documentation.
IMHO, the project is still evolving as some others
Great! Thanks to all of you. It would be ideal to host the docs with the
code, and I'd be more than happy to help out myself.
I'm in the process of implementing a Python desktop client which would work
with WiaB, and would greatly appreciate any documentation made available.
Having someo
ngerous to jump head-long into WiaB until
it's ready for prime time.
-H
On Sat, Dec 11, 2010 at 12:03 PM, Torben Weis wrote:
> 2010/12/11 Juan Luis Chulilla
>
> > Excuse me if I say something stupid, but why documentation is not
> > maintained inside a wave? Is it not fea
2010/12/11 Juan Luis Chulilla
> Excuse me if I say something stupid, but why documentation is not
> maintained inside a wave? Is it not feasible now to do that in a
> instance of wave in a box? I mean, Google sites is fine, but using a
>
Unless we have a stable instance of WiaB
Excuse me if I say something stupid, but why documentation is not
maintained inside a wave? Is it not feasible now to do that in a
instance of wave in a box? I mean, Google sites is fine, but using a
set of waves would be great, specially in terms of morale. Think that
a lot of users were
Chulilla
> Congratulations for the initiative. (Apache) Wave is so complex that a
> proper documentation is mandatory in order to helping new developers.
>
> I would like to contribute to it if it is possible. I am not a
> developer, but I can conduct QA tasks with it and translate it
Congratulations for the initiative. (Apache) Wave is so complex that a
proper documentation is mandatory in order to helping new developers.
I would like to contribute to it if it is possible. I am not a
developer, but I can conduct QA tasks with it and translate it into
Spanish.
Best regards
anael Abbotts" wrote:
>
> >As the project plans to move to a new home at Apache, I feel quite
> strongly
> >that it would be a very good idea to draft up some whitepapers (or
> similar)
> >clarifying some things that there appears to be quite a bit of confusion
>
As the project plans to move to a new home at Apache, I feel quite strongly
that it would be a very good idea to draft up some whitepapers (or similar)
clarifying some things that there appears to be quite a bit of confusion
about.
Good code requires good planning and good documentation, and so
83 matches
Mail list logo
