[Pyogp] pyogp wiki structure proposal

[Enus Linden]

I've sketched out a suggested wiki stucture for Pyogp on
wiki.secondlife.com. Please take a look and make suggestions for
improvement as needed. Tech detail pages are particularly onerous
imo.... I'd like to keep things as simple and consolidated as possible.
Tutorial pages may need a specific home, though
Pyogp/Documentation/Tutorials could exist (separate from
Pyogp/Documentation/Examples).

https://wiki.secondlife.com/wiki/User:Enus_Linden/Project-Wiki-Structure

Nothing's perfect, please provide feedback per omissions or structure
improvements, etc...

enus

[Christian Scholz]

Hi!

Post by Enus Linden
I've sketched out a suggested wiki stucture for Pyogp on
wiki.secondlife.com. Please take a look and make suggestions for
improvement as needed. Tech detail pages are particularly onerous
imo.... I'd like to keep things as simple and consolidated as possible.
Tutorial pages may need a specific home, though
Pyogp/Documentation/Tutorials could exist (separate from
Pyogp/Documentation/Examples).
https://wiki.secondlife.com/wiki/User:Enus_Linden/Project-Wiki-Structure

Structure in general looks good but one thing I would like is a shorter
first page. It's a bit overwhelming I think.

What about having a 1-2 line introduction, then 2 links to the library
and the test harness (the details about them can be explained on these
pages). I am also not sure we need the whole history there and explain
AWG and OGP there. These can IMHO be linked to separate pages in case
people do not know about them (chance is though that they know about it
and this is why they came to those wiki pages).

And why not put roadmap and status on separate pages? Maybe even
separately for the subprojects lib and test harness. Reason for this:
These are more changing pages while I would think of the start page more
or less as a table of contents where you can quickly find those links
which you are looking for.

In the end I would put short overview of ways to participate:

- where to find the repository
- list of meetings
- mailing list, IRC channel

Chat transcripts etc. maybe on a different page?

That's my $0.02 on it.

-- Christian

[Lock'a Mail]

I put changes in *bold*:

1. Make a decision about grok
- look at Tao's grok branch
- look at grokcore.component to find what is being taken in
- list benefits/disadvantages (for grok, and other things we could use)

2. Decide about webob
- Tao, convince us
- look at webob and determine if it's something we can't whip up
ourselves
- list benefits/disadvantages (for this and for other things, such as
doing it ourselves)

3. Find out about teleport with public beta
- what needs to be done to teleport? is it based on teleport strawman?

4. OGP tests
- should be starting to write documentation on the Login (just login?)
protocols and how
they should be tested (Infinity has started on this. Link to the
page?)
- should be tests for agent domain - region domain (sim)
communication. In particular, we should
have tests written for request_rez_avatar
- auth.py tests?

5. Collaborate with Interop
- we need to get in contact with interop more to get more detailed
information about what they
want and how they intend to use Pyogp

6. Start on messaging system
- find out the true scope of the messages that will be sent, the ways
we need to serialize, what components we will need to get this done
(Builder, Parser, Reader)
- write tests for how we want this to be used (this may be hard at
this point because we don't
know scope)
- write tests for the current parser
- refactor the parser to follow the "NEW" coding standard we adopted
*- network layer swapability*

7. Agent Domain
- Tao has been working on writing an agent domain
- blocked by his inability to connect to our regions

8. Task tracking
- pjira, or some other form

9. Refactor the wiki
- what part of the wiki is poor as it currently is?
- reword the stuff in the test harness page to make it clear that we
won't be building a framework, but simply using a framework
(PyUnit, doctest, py.test) to create test suites for both the
client lib AND servers running OGP protocols
- check out Enus' layout
https://wiki.secondlife.com/wiki/User:Enus_Linden/Project-Wiki-Structure

*10. Test harness
- get testing set up for the test harness (similar to bin\test)
- move test_ogplogin.py to the test harness side*

[Christian Scholz]

Hi!

Thanks for that list :-)
(but we need to move such things to jira, right?)

Post by Lock'a Mail
1. Make a decision about grok
- look at Tao's grok branch
- look at grokcore.component to find what is being taken in
- list benefits/disadvantages (for grok, and other things we could use)
2. Decide about webob
- Tao, convince us
- look at webob and determine if it's something we can't whip up ourselves
- list benefits/disadvantages (for this and for other things, such as
doing it ourselves)
3. Find out about teleport with public beta
- what needs to be done to teleport? is it based on teleport strawman?
4. OGP tests
- should be starting to write documentation on the Login (just login?)
protocols and how
they should be tested (Infinity has started on this. Link to the page?)
- should be tests for agent domain - region domain (sim) communication.
In particular, we should
have tests written for request_rez_avatar
- auth.py tests?
5. Collaborate with Interop
- we need to get in contact with interop more to get more detailed
information about what they
want and how they intend to use Pyogp
6. Start on messaging system
- find out the true scope of the messages that will be sent, the ways
we need to serialize, what components we will need to get this done
(Builder, Parser, Reader)
- write tests for how we want this to be used (this may be hard at this
point because we don't
know scope)
- write tests for the current parser
- refactor the parser to follow the "NEW" coding standard we adopted
*- network layer swapability*
7. Agent Domain
- Tao has been working on writing an agent domain
- blocked by his inability to connect to our regions
8. Task tracking
- pjira, or some other form
9. Refactor the wiki
- what part of the wiki is poor as it currently is?
- reword the stuff in the test harness page to make it clear that we
won't be building a framework, but simply using a framework
(PyUnit, doctest, py.test) to create test suites for both the
client lib AND servers running OGP protocols
- check out Enus' layout
https://wiki.secondlife.com/wiki/User:Enus_Linden/Project-Wiki-Structure
*10. Test harness
- get testing set up for the test harness (similar to bin\test)
- move test_ogplogin.py to the test harness side*
_______________________________________________
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp

[Christian Scholz]

Damn, hit Enter accidently too early and sent it.

Post by Lock'a Mail
2. Decide about webob
- Tao, convince us

Well, whenever there is a component which somebody already has
programmed I would think we should use it and somebody should actually
convince the rest why we should not use it ;-)

Please also look at the list of already existing Request/Response objects:

http://pythonpaste.org/webob/differences.html

Do we really want to add yet another implementation to that list and
confuse people when dealing with such objects?

My proposal would be that I start with using webob and if somebody feels
inclined to do so he/she can implement a replacement. But if we first
implement a replacement then I at least would be blocked with the
networking layer.

Post by Lock'a Mail
- look at webob and determine if it's something we can't whip up ourselves
- list benefits/disadvantages (for this and for other things, such as
doing it ourselves)
3. Find out about teleport with public beta
- what needs to be done to teleport? is it based on teleport strawman?

OpenSim seems not to use request_rez_avatar at the moment. The data
structure of rez_avatar also seems slightly different than defined in
the strawman (mainly the whole dict is wrapped into a dict in an
'agent_params' key).

Post by Lock'a Mail
4. OGP tests
- should be starting to write documentation on the Login (just login?)
protocols and how
they should be tested (Infinity has started on this. Link to the page?)
- should be tests for agent domain - region domain (sim) communication.
In particular, we should
have tests written for request_rez_avatar
- auth.py tests?

Do you mean test harness here? I think we should move all those tests
which rely on outside servers to test harness and make those servers
configurable. No idea how right now but there should be some solution.

As for the pyogp tests I would like to have those self-contained, which
means that no external server should be needed. Right now to run my
doctests you have to start a mockup server via bin/testserver but I hope
to get rid of this soon and make it fully automatable.
Goal should be that the tests run at all times (all tests) without any
extra setup.

Post by Lock'a Mail
5. Collaborate with Interop
- we need to get in contact with interop more to get more detailed
information about what they
want and how they intend to use Pyogp
6. Start on messaging system
- find out the true scope of the messages that will be sent, the ways
we need to serialize, what components we will need to get this done
(Builder, Parser, Reader)
- write tests for how we want this to be used (this may be hard at this
point because we don't
know scope)
- write tests for the current parser
- refactor the parser to follow the "NEW" coding standard we adopted
*- network layer swapability*
7. Agent Domain
- Tao has been working on writing an agent domain
- blocked by his inability to connect to our regions

Now blocked by maybe some bug in the OpenSim code which makes rez_avatar
only to work once. After that my user is known and some exception is
raised. The question is: Whom to ask? Is there collaboration going on
between OpenSim and IBM? Who does know more details about the patch and
how is integration of it into OpenSim going along?
(maybe a topic for gridnauts?)

Post by Lock'a Mail
8. Task tracking
- pjira, or some other form
9. Refactor the wiki
- what part of the wiki is poor as it currently is?
- reword the stuff in the test harness page to make it clear that we
won't be building a framework, but simply using a framework
(PyUnit, doctest, py.test) to create test suites for both the
client lib AND servers running OGP protocols
- check out Enus' layout
https://wiki.secondlife.com/wiki/User:Enus_Linden/Project-Wiki-Structure
*10. Test harness
- get testing set up for the test harness (similar to bin\test)
- move test_ogplogin.py to the test harness side*

I think test_request_rez_avatar should go there aswell. Esp. as it's not
working for me at all as I am outside your firewall and no connection is
made.

Tasks I would have:

- Write down best practices for development
- Get the network layer implemented on a branch
- Clean up the serialization layer before we add more things which needs
it (get rid of ICredentialSerialzer and instead use a generic
ISerialization interface)

So much for my remarks.

Good list :-)

-- Christian

[Locklainn]

So, I don't think you sent the email that you thought you sent? (get
that? haha)
This was the only one I got about a task update from you

Post by Christian Scholz
Damn, hit Enter accidently too early and sent it.

Post by Lock'a Mail
2. Decide about webob
- Tao, convince us

Well, whenever there is a component which somebody already has
programmed I would think we should use it and somebody should actually
convince the rest why we should not use it ;-)
http://pythonpaste.org/webob/differences.html
Do we really want to add yet another implementation to that list and
confuse people when dealing with such objects?
My proposal would be that I start with using webob and if somebody
feels inclined to do so he/she can implement a replacement. But if we
first implement a replacement then I at least would be blocked with
the networking layer.

Post by Lock'a Mail
- look at webob and determine if it's something we can't whip up ourselves
- list benefits/disadvantages (for this and for other things, such
as doing it ourselves)
3. Find out about teleport with public beta
- what needs to be done to teleport? is it based on teleport strawman?

OpenSim seems not to use request_rez_avatar at the moment. The data
structure of rez_avatar also seems slightly different than defined in
the strawman (mainly the whole dict is wrapped into a dict in an
'agent_params' key).

Post by Lock'a Mail
4. OGP tests
- should be starting to write documentation on the Login (just
login?) protocols and how
they should be tested (Infinity has started on this. Link to the page?)
- should be tests for agent domain - region domain (sim)
communication. In particular, we should
have tests written for request_rez_avatar
- auth.py tests?

Do you mean test harness here? I think we should move all those tests
which rely on outside servers to test harness and make those servers
configurable. No idea how right now but there should be some solution.
As for the pyogp tests I would like to have those self-contained,
which means that no external server should be needed. Right now to run
my doctests you have to start a mockup server via bin/testserver but I
hope to get rid of this soon and make it fully automatable.
Goal should be that the tests run at all times (all tests) without any
extra setup.

Post by Lock'a Mail
5. Collaborate with Interop
- we need to get in contact with interop more to get more detailed
information about what they
want and how they intend to use Pyogp
6. Start on messaging system
- find out the true scope of the messages that will be sent, the
ways we need to serialize, what components we will need to get
this done (Builder, Parser, Reader)
- write tests for how we want this to be used (this may be hard at
this point because we don't
know scope)
- write tests for the current parser
- refactor the parser to follow the "NEW" coding standard we adopted
*- network layer swapability*
7. Agent Domain
- Tao has been working on writing an agent domain
- blocked by his inability to connect to our regions

Now blocked by maybe some bug in the OpenSim code which makes
rez_avatar only to work once. After that my user is known and some
exception is raised. The question is: Whom to ask? Is there
collaboration going on between OpenSim and IBM? Who does know more
details about the patch and how is integration of it into OpenSim
going along?
(maybe a topic for gridnauts?)

Post by Lock'a Mail
8. Task tracking
- pjira, or some other form
9. Refactor the wiki
- what part of the wiki is poor as it currently is?
- reword the stuff in the test harness page to make it clear that we
won't be building a framework, but simply using a framework
(PyUnit, doctest, py.test) to create test suites for both the
client lib AND servers running OGP protocols
- check out Enus' layout
https://wiki.secondlife.com/wiki/User:Enus_Linden/Project-Wiki-Structure
*10. Test harness
- get testing set up for the test harness (similar to bin\test)
- move test_ogplogin.py to the test harness side*

I think test_request_rez_avatar should go there aswell. Esp. as it's
not working for me at all as I am outside your firewall and no
connection is made.
- Write down best practices for development
- Get the network layer implemented on a branch
- Clean up the serialization layer before we add more things which
needs it (get rid of ICredentialSerialzer and instead use a generic
ISerialization interface)
So much for my remarks.
Good list :-)
-- Christian

[Timothy Loughlin (Locklainn Linden)]

Post by Christian Scholz
Do you mean test harness here? I think we should move all those tests
which rely on outside servers to test harness and make those servers
configurable. No idea how right now but there should be some solution.
As for the pyogp tests I would like to have those self-contained,
which means that no external server should be needed. Right now to run
my doctests you have to start a mockup server via bin/testserver but I
hope to get rid of this soon and make it fully automatable.
Goal should be that the tests run at all times (all tests) without any
extra setup.

I agree. I do mean test harness in this case as well.

Post by Christian Scholz
Now blocked by maybe some bug in the OpenSim code which makes
rez_avatar only to work once. After that my user is known and some
exception is raised. The question is: Whom to ask? Is there
collaboration going on between OpenSim and IBM? Who does know more
details about the patch and how is integration of it into OpenSim
going along?
(maybe a topic for gridnauts?)

Yea, try gridnauts.

Post by Christian Scholz
I think test_request_rez_avatar should go there aswell. Esp. as it's
not working for me at all as I am outside your firewall and no
connection is made.

Yep, I agree.

Post by Christian Scholz
- Write down best practices for development
- Get the network layer implemented on a branch
- Clean up the serialization layer before we add more things which
needs it (get rid of ICredentialSerialzer and instead use a generic
ISerialization interface)

I'll add these to the task list

[Timothy Loughlin (Locklainn Linden)]

I put changes in *bold*:

*0. Write down best practices for development*

1. Make a decision about grok
- look at Tao's grok branch
- look at grokcore.component to find what is being taken in
- list benefits/disadvantages (for grok, and other things we could use)

2. Decide about webob
- Tao, convince us
- look at webob and determine if it's something we can't whip up ourselves
- list benefits/disadvantages (for this and for other things, such as
doing it ourselves)

3. Find out about teleport with public beta
- what needs to be done to teleport? is it based on teleport strawman?

4. OGP tests
- should be starting to write documentation on the Login (just login?)
protocols and how
they should be tested (Infinity has started on this. Link to the page?)
- should be tests for agent domain - region domain (sim) communication.
In particular, we should
have tests written for request_rez_avatar
- auth.py tests?

5. Collaborate with Interop
- we need to get in contact with interop more to get more detailed
information about what they
want and how they intend to use Pyogp

6. Start on messaging system
- find out the true scope of the messages that will be sent, the ways
we need to serialize, what components we will need to get this done
(Builder, Parser, Reader)
- write tests for how we want this to be used (this may be hard at this
point because we don't
know scope)
- write tests for the current parser
- refactor the parser to follow the "NEW" coding standard we adopted
- network layer swapability *- implemented on a branch
*
7. Agent Domain
- Tao has been working on writing an agent domain
- blocked by his inability to connect to our regions

8. Task tracking
- pjira, or some other form

9. Refactor the wiki
- what part of the wiki is poor as it currently is?
- reword the stuff in the test harness page to make it clear that we
won't be building a framework, but simply using a framework
(PyUnit, doctest, py.test) to create test suites for both the
client lib AND servers running OGP protocols
- check out Enus' layout
https://wiki.secondlife.com/wiki/User:Enus_Linden/Project-Wiki-Structure

10. Test harness
- get testing set up for the test harness (similar to bin\test)
- move test_ogplogin.py to the test harness side
- move test_request_rez_avatar to the test harness side

*11. Clean up the serialization layer before we add more things which
needs it (get rid of
ICredentialSerialzer and instead use a generic ISerialization
interface)
*

[Lawson English]

Post by Christian Scholz
Damn, hit Enter accidently too early and sent it.

Post by Lock'a Mail
2. Decide about webob
- Tao, convince us

Well, whenever there is a component which somebody already has
programmed I would think we should use it and somebody should actually
convince the rest why we should not use it ;-)

I guess two questions come to mind: 1) is it compatible with eventlet,
and 2) does it lock us into language-specific features?

one of the biggest issues with libsl and OGP is the .net-specific stuff.
Makes it really easy to code, but libsl's dependence on .net is one
important reason why the AWG could never use it as the reference
platform for OGP, so we have to watch that we don't make the same
ease-of-programming error with pyogp. It's not JUST a reference library,
but I think that that is one of the purposes for creating it and we
should keep that in mind when we decide on these things.


Lawson

[Christian Scholz]

Hi!

Post by Lawson English

Post by Christian Scholz
Damn, hit Enter accidently too early and sent it.

Post by Lock'a Mail
2. Decide about webob
- Tao, convince us

Well, whenever there is a component which somebody already has
programmed I would think we should use it and somebody should actually
convince the rest why we should not use it ;-)

I guess two questions come to mind: 1) is it compatible with eventlet,
and 2) does it lock us into language-specific features?

The idea behind using that Request object is to abstract the network
layer from the implementation. The implementation could be urllib2,
eventlet or whatever. Any Request/Response object should be able to be
converted to what those implementations support quite easily
Moreover WebOb supports WSGI which eventlet also supports.

I don't get your point about the language specific stuff. Of course we
are language-specific in that we use Python all over pyogp.
Is what you mean more platform-specific, as .NET is more the platform
while C# is one of the languages you can use on it?

.NET is a runtime which means that you cannot simply take C#
applications and run them elsewhere. It's a virtual machine executing
your program.
Python does not have such a VM although it was discussed during Guido's
keynote at EuroPython. His opinion was that no such thing as a python
specific VM is needed as there are many out there already and the future
will be more that those VMs will become more generic and support more
than just one language (what .NET/Mono actually already does).

To come back to your question: All this stuff does not rely on such a
virtual machine or platform, it's pure Python and WebOb is just a small
library we add.

I am not sure it answers your question but I hope so.

cheers,

Christian

PS: Unfortunately the keynote recording is still not online as least afaik.

Post by Lawson English
one of the biggest issues with libsl and OGP is the .net-specific stuff.
Makes it really easy to code, but libsl's dependence on .net is one
important reason why the AWG could never use it as the reference
platform for OGP, so we have to watch that we don't make the same
ease-of-programming error with pyogp. It's not JUST a reference library,
but I think that that is one of the purposes for creating it and we
should keep that in mind when we decide on these things.
Lawson
_______________________________________________
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp

[Tess Chu]

These three tasks below are related, and I can help provide some context
since I'm currently working on Interop.

Post by Lock'a Mail
3. Find out about teleport with public beta
- what needs to be done to teleport? is it based on teleport strawman?
4. OGP tests
- should be starting to write documentation on the Login (just
login?) protocols and how
they should be tested (Infinity has started on this. Link to the
page?)
- should be tests for agent domain - region domain (sim)
communication. In particular, we should
have tests written for request_rez_avatar
- auth.py tests?
5. Collaborate with Interop
- we need to get in contact with interop more to get more detailed
information about what they
want and how they intend to use Pyogp

The final protocol will be defined here:
https://wiki.secondlife.com/wiki/SLGOGP_Draft_1 (Needs to be renamed to
OGP) but for now, Zero is a little behind so everything pending to be in
the OGP is implemented against the strawman:
https://wiki.secondlife.com/wiki/SLGOGP_Teleport_Strawman

Tests should be written against the OGP/Strawman, which currently
includes login and teleport, which includes auth.py as well as
rez_avatar/request (see strawman). Although OpenSim does not use
rez_avatar/request *yet* it *will* for the July 31st Beta, so these
tests need to work against the protocol, and so does the OpenSim code.

Apologies for the late documentation on this, but I've just pulled in
the internal flow chart into the Strawman which includes details on
auth.py. https://wiki.secondlife.com/wiki/SLGOGP_Teleport_Strawman#Login

Post by Lock'a Mail
6. Start on messaging system
- find out the true scope of the messages that will be sent, the ways
we need to serialize, what components we will need to get this
done (Builder, Parser, Reader)
- write tests for how we want this to be used (this may be hard at
this point because we don't
know scope)
- write tests for the current parser
- refactor the parser to follow the "NEW" coding standard we adopted
*- network layer swapability*

So far, only legacy stuff requires UDP messages, and we're working on
trying to get rid of them for the OGP. Most of what happens during
login is handshaking to set up the UDP messaging system, but we want to
concentrate on the HTTP messages via Caps for OGP testing.

Post by Lock'a Mail
7. Agent Domain
- Tao has been working on writing an agent domain
- blocked by his inability to connect to our regions
8. Task tracking
- pjira, or some other form
9. Refactor the wiki
- what part of the wiki is poor as it currently is?
- reword the stuff in the test harness page to make it clear that we
won't be building a framework, but simply using a framework
(PyUnit, doctest, py.test) to create test suites for both the
client lib AND servers running OGP protocols
- check out Enus' layout
https://wiki.secondlife.com/wiki/User:Enus_Linden/Project-Wiki-Structure
*10. Test harness
- get testing set up for the test harness (similar to bin\test)
- move test_ogplogin.py to the test harness side*
_______________________________________________
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp

[Tess Chu]

Post by Christian Scholz
What about having a 1-2 line introduction, then 2 links to the library
and the test harness (the details about them can be explained on these
pages). I am also not sure we need the whole history there and explain
AWG and OGP there. These can IMHO be linked to separate pages in case
people do not know about them (chance is though that they know about
it and this is why they came to those wiki pages).

Yes, an introduction section would be nice, and should include links to
AWG and OGP. There's not really much real "history" but rather just
"background" information that should belong in the introduction. Of
course we'd also have those links under the "Links" section.

Post by Christian Scholz
And why not put roadmap and status on separate pages?

I would like to have the status *with* the roadmap. Those who are
interested in status should also know its relation to the roadmap. It's
hard to communicate "where are we" if we don't know "where we want to
be." If anything, you're going to have many statuses in the roadmap
because many people are working on many things. Note that this is going
to be a high-level status and we should really be linking to Jira for
task level status since that will change *all the time*.

Post by Christian Scholz
Maybe even separately for the subprojects lib and test harness. Reason
for this: These are more changing pages while I would think of the
start page more or less as a table of contents where you can quickly
find those links which you are looking for.

I like this. We probably need a separate "Library Roadmap" and "Test
Roadmap". Furthermore, I would like the folks doing library changes to
be more careful about merging their changes in because the other folks
doing test changes will want the libraries in a stable state so that
they're not constantly going back to the library folks for bug fixes.
One way to do this is to have a separate branch for each milestone that
merges up periodically.

Post by Christian Scholz
- where to find the repository
- list of meetings
- mailing list, IRC channel

I think this should go in the beginning. Most people looking at this
page wants to get started right away. I think Enus already has it that way.

[Christian Scholz]

Post by Tess Chu

Post by Christian Scholz
What about having a 1-2 line introduction, then 2 links to the library
and the test harness (the details about them can be explained on these
pages). I am also not sure we need the whole history there and explain
AWG and OGP there. These can IMHO be linked to separate pages in case
people do not know about them (chance is though that they know about
it and this is why they came to those wiki pages).

Yes, an introduction section would be nice, and should include links to
AWG and OGP. There's not really much real "history" but rather just
"background" information that should belong in the introduction. Of
course we'd also have those links under the "Links" section.

Post by Christian Scholz
And why not put roadmap and status on separate pages?

I would like to have the status *with* the roadmap. Those who are
interested in status should also know its relation to the roadmap. It's
hard to communicate "where are we" if we don't know "where we want to
be." If anything, you're going to have many statuses in the roadmap
because many people are working on many things. Note that this is going
to be a high-level status and we should really be linking to Jira for
task level status since that will change *all the time*.

Well, I meant more that Roadmap and Status should not be directly on the
homepage but linked from their. I am ok with both being on one page and
jira links make sense of course, too. It would even be nice if one could
group JIRA tasks into milestones and list these automatically on that page.

Post by Tess Chu

Post by Christian Scholz
Maybe even separately for the subprojects lib and test harness. Reason
for this: These are more changing pages while I would think of the
start page more or less as a table of contents where you can quickly
find those links which you are looking for.

I like this. We probably need a separate "Library Roadmap" and "Test
Roadmap". Furthermore, I would like the folks doing library changes to
be more careful about merging their changes in because the other folks
doing test changes will want the libraries in a stable state so that
they're not constantly going back to the library folks for bug fixes.
One way to do this is to have a separate branch for each milestone that
merges up periodically.

+1

Post by Tess Chu

Post by Christian Scholz
- where to find the repository
- list of meetings
- mailing list, IRC channel

I think this should go in the beginning. Most people looking at this
page wants to get started right away. I think Enus already has it that way.

Sure, my idea was though to have the homepage that small that it fits on
one screen. Then you would see all information. So I think of it more
being a table of contents with many sublinks in a structured way so that
it's easy to comprehend in one glance.

-- Christian

[Enus Linden]

I'll work today to firm this up and see how far I get in executing
against the structure with the feedback incorporated.

I said this in an internal meeting yesterday, and I want to re-assert in
the public domain: I am floored and impressed by what pyogp has become
in the past few weeks, and am grateful for the effort, efficiency and
productivity of those who are contributing. Tao, Locklainn, Infinity,
WOW... thank you so much. I am very much looking forward to watching
this effort mature.

Post by Christian Scholz

Post by Tess Chu

Post by Christian Scholz
What about having a 1-2 line introduction, then 2 links to the
library and the test harness (the details about them can be
explained on these pages). I am also not sure we need the whole
history there and explain AWG and OGP there. These can IMHO be
linked to separate pages in case people do not know about them
(chance is though that they know about it and this is why they came
to those wiki pages).

Yes, an introduction section would be nice, and should include links
to AWG and OGP. There's not really much real "history" but rather
just "background" information that should belong in the
introduction. Of course we'd also have those links under the "Links"
section.

Post by Christian Scholz
And why not put roadmap and status on separate pages?

I would like to have the status *with* the roadmap. Those who are
interested in status should also know its relation to the roadmap.
It's hard to communicate "where are we" if we don't know "where we
want to be." If anything, you're going to have many statuses in the
roadmap because many people are working on many things. Note that
this is going to be a high-level status and we should really be
linking to Jira for task level status since that will change *all the
time*.

Well, I meant more that Roadmap and Status should not be directly on
the homepage but linked from their. I am ok with both being on one
page and jira links make sense of course, too. It would even be nice
if one could group JIRA tasks into milestones and list these
automatically on that page.

Post by Tess Chu

Post by Christian Scholz
Maybe even separately for the subprojects lib and test harness.
Reason for this: These are more changing pages while I would think
of the start page more or less as a table of contents where you can
quickly find those links which you are looking for.

I like this. We probably need a separate "Library Roadmap" and "Test
Roadmap". Furthermore, I would like the folks doing library changes
to be more careful about merging their changes in because the other
folks doing test changes will want the libraries in a stable state so
that they're not constantly going back to the library folks for bug
fixes. One way to do this is to have a separate branch for each
milestone that merges up periodically.

+1

Post by Tess Chu

Post by Christian Scholz
- where to find the repository
- list of meetings
- mailing list, IRC channel

I think this should go in the beginning. Most people looking at this
page wants to get started right away. I think Enus already has it that way.

Sure, my idea was though to have the homepage that small that it fits
on one screen. Then you would see all information. So I think of it
more being a table of contents with many sublinks in a structured way
so that it's easy to comprehend in one glance.
-- Christian

[Lawson English]

Post by Enus Linden
I'll work today to firm this up and see how far I get in executing
against the structure with the feedback incorporated.
I said this in an internal meeting yesterday, and I want to re-assert
in the public domain: I am floored and impressed by what pyogp has
become in the past few weeks, and am grateful for the effort,
efficiency and productivity of those who are contributing. Tao,
Locklainn, Infinity, WOW... thank you so much. I am very much looking
forward to watching this effort mature.

So am I. Was commenting to Zha last night that I am SOOO out of my
league here...

But I'm watching and trying to learn and contribute what little I can.

L.