Difference between revisions of "FirstTimers"
RjS-legacy (talk | contribs) (New page: Greetings! Many first time attendees have registered for the next SIPIT. This page is intended to give those implementors an idea of what to expect at the event. The SIPIT events are not...) |
RjS-legacy (talk | contribs) |
||
| Line 11: | Line 11: | ||
Each SIPit has an associated wiki where the attendees share information about thier implementation, describe what they want to test during the week and manage their schedule. Some participants try to pre-schedule, but most find they spend parts of the first day meeting other implementors, finding people to test with through the week and establishing a thumbnail schedule. Be prepared for this schedule to change frequently. The person you've arranged to meet with at 2, for instance, may find themselves in the middle of debugging a problem with their previous engagement, and will have to reschedule. | Each SIPit has an associated wiki where the attendees share information about thier implementation, describe what they want to test during the week and manage their schedule. Some participants try to pre-schedule, but most find they spend parts of the first day meeting other implementors, finding people to test with through the week and establishing a thumbnail schedule. Be prepared for this schedule to change frequently. The person you've arranged to meet with at 2, for instance, may find themselves in the middle of debugging a problem with their previous engagement, and will have to reschedule. | ||
| − | In addition to the peer-to-peer tests, we run a series of more structured multiparty tests. These typically involve 4-12 implementations and focus on either very new additions to the protocol suite or scenarios that require this many participants to make sense. Descriptions of some of these tests can be found on this multiparty test page. | + | In addition to the peer-to-peer tests, we run a series of more structured multiparty tests. These typically involve 4-12 implementations and focus on either very new additions to the protocol suite or scenarios that require this many participants to make sense. Descriptions of some of these tests can be found on this multiparty test page. The multiparty tests will take half a day each. It is not necessary to sign-up for them ahead of time. Multiparty tests are a good way to start your SIPit work, meeting other people and often very helpful engineers. You will learn a lot about the technology and your product by participating! |
| − | The multiparty tests will take half a day each. It is not necessary to sign-up for them ahead of time. | ||
| − | If you're not already subscribed, join the sip-implementor's list. There are instructions for subscribing at http://www.cs.columbia.edu/sip/list.html . There is often discussion of the multiparty tests before the event on that list. | + | If you're not already subscribed, join the sip-implementor's list. There are instructions for subscribing at http://www.cs.columbia.edu/sip/list.html . There is often discussion of the multiparty tests before the event on that list. |
| + | |||
| + | Other things you should know: | ||
| + | * Don't forget your business cards. When remembering all your kit they're easy to forget. | ||
| + | * Don't schedule the things you really care about for Monday, or for 9:00. That seems to be when most things are broken! Later in the week and later in the day things generally run smoother. | ||
| + | * If you have clients or servers that can be started and can run unattended (for other people to test with), place the information on your wiki page. Then people can test already some basic things before starting the ''real'' test sessions. | ||
| + | * Try to leave some time at the end of the week to retest with people once you've added some fixes. | ||
| + | |||
| + | Be sure to add your team to the "Team Registration and Request for IP addresses" on the event wiki as soon as you register. It's very important to provide accurate information there as early as possible. | ||
Latest revision as of 17:09, 30 March 2008
Greetings!
Many first time attendees have registered for the next SIPIT. This page is intended to give those implementors an idea of what to expect at the event.
The SIPIT events are not open to the general public - only the individuals who have registered for the event are allowed on the test floor, and you must have an implementation to register. This is a test event, not a showcase or a trade show.
The event has a very friendly and supportive atmosphere. Companies tend to bring both production and cutting-edge versions of thier implementations. The point of the event is to test and improve the quality of the SIP specification. Everyone's implementation improves as a natural side effect. While there is no formal non-disclosure agreement, the spirit of the event is to keep the details of testing confidential.
The majority of the testing at the event is peer-to-peer and the participants are in total control of both the scheduling and what gets tested. Whether you have a very early implementation with large missing sections, or a robust well-seasoned implementation, you'll find peers to test almost any scenario you can think of. You'll see special interest (lots of implementations wanting to test) around any new extension that's being actively worked on in the IETF.
Each SIPit has an associated wiki where the attendees share information about thier implementation, describe what they want to test during the week and manage their schedule. Some participants try to pre-schedule, but most find they spend parts of the first day meeting other implementors, finding people to test with through the week and establishing a thumbnail schedule. Be prepared for this schedule to change frequently. The person you've arranged to meet with at 2, for instance, may find themselves in the middle of debugging a problem with their previous engagement, and will have to reschedule.
In addition to the peer-to-peer tests, we run a series of more structured multiparty tests. These typically involve 4-12 implementations and focus on either very new additions to the protocol suite or scenarios that require this many participants to make sense. Descriptions of some of these tests can be found on this multiparty test page. The multiparty tests will take half a day each. It is not necessary to sign-up for them ahead of time. Multiparty tests are a good way to start your SIPit work, meeting other people and often very helpful engineers. You will learn a lot about the technology and your product by participating!
If you're not already subscribed, join the sip-implementor's list. There are instructions for subscribing at http://www.cs.columbia.edu/sip/list.html . There is often discussion of the multiparty tests before the event on that list.
Other things you should know:
- Don't forget your business cards. When remembering all your kit they're easy to forget.
- Don't schedule the things you really care about for Monday, or for 9:00. That seems to be when most things are broken! Later in the week and later in the day things generally run smoother.
- If you have clients or servers that can be started and can run unattended (for other people to test with), place the information on your wiki page. Then people can test already some basic things before starting the real test sessions.
- Try to leave some time at the end of the week to retest with people once you've added some fixes.
Be sure to add your team to the "Team Registration and Request for IP addresses" on the event wiki as soon as you register. It's very important to provide accurate information there as early as possible.