Difference between revisions of "Participating"
Jump to navigation
Jump to search
m (Text replacement - "http://lecs.opensource.secondlife.com/" to "http://lecs-opensource.secondlife.com/") |
|||
| (7 intermediate revisions by 7 users not shown) | |||
| Line 3: | Line 3: | ||
Ways to partcipate | Ways to partcipate | ||
* '''{{OSWiki|Downloading test builds|alt=Download a test build}}''' - try downloading | * '''{{OSWiki|Downloading test builds|alt=Download a test build}}''' - try downloading and testing out the latest version of the software. | ||
* '''{{OSWiki|Communication tools|alt=Communicate}}''' - Let us know what you think | * '''{{OSWiki|Communication tools|alt=Communicate}}''' - Let us know what you think by email, on the forum, or IRC. If it's not working for you, try to get help there. If it is working for you, try helping someone who isn't having as much luck as you are. | ||
* '''{{OSWiki|Get source and compile|alt=Get source and compile}}''' - Download and compile - even if you don't plan to develop, just the act of downloading and compiling can uncover problems. If the version you download doesn't build on your platform, file a bug. | * '''{{OSWiki|Get source and compile|alt=Get source and compile}}''' - Download and compile - even if you don't plan to develop, just the act of downloading and compiling can uncover problems. If the version you download doesn't build on your platform, file a bug. | ||
* Developers are encouraged to complete the [http://lecs-opensource.secondlife.com/SLVcontribution_agmt.pdf Second Life Viewer Contributor Agreement]. Submissions to Snowglobe cannot be included in the official Second Life Viewer without this agreement in place. | |||
* '''{{OSWiki|Bug_Reporting_101|alt=File and vet bugs}}''' - if you run into issues, look through the bug database and see if a bug has been filed. If so, vote for the issue to be fixed. If not, file the bug. Vetting bugs is just as important (if not more so) than filing bugs. We need to know whether each bug that's been filed is a problem for one person, or a problem for many. Try reproducing some of the bugs that have been filed, and see if they are problems for you. If you can't figure out how to reproduce the problem, make a comment on the bug, asking the person to describe their problem in more detail. | * '''{{OSWiki|Bug_Reporting_101|alt=File and vet bugs}}''' - if you run into issues, look through the bug database and see if a bug has been filed. If so, vote for the issue to be fixed. If not, file the bug. Vetting bugs is just as important (if not more so) than filing bugs. We need to know whether each bug that's been filed is a problem for one person, or a problem for many. Try reproducing some of the bugs that have been filed, and see if they are problems for you. If you can't figure out how to reproduce the problem, make a comment on the bug, asking the person to describe their problem in more detail. | ||
* '''{{OSWiki|Feature requests|alt=File and refine feature requests}}''' - We're always looking for new ideas. Please let us know what you would like to see done. Also, features are more likely to get implemented if the description of the feature is clear. For a complicated feature, a link to a specification on the wiki is a great way to help flesh out the idea. | * '''{{OSWiki|Feature requests|alt=File and refine feature requests}}''' - We're always looking for new ideas. Please let us know what you would like to see done. Also, features are more likely to get implemented if the description of the feature is clear. For a complicated feature, a link to a specification on the wiki is a great way to help flesh out the idea. | ||
* '''{{OSWiki|Profiling and Optimization|alt=Profile and optimize}}''' - If you're interested in improving the performance of the software, take a look at these notes on how to profile and optimize code. | |||
* '''{{OSWiki|Creating a version control repository|alt=Create a version control repository}}''' - if you make extensive changes to the source download packages, it is easy to lose track of what files you changed, as well as remembering what you did and when. A version control repository keeps track of these file changes for you automatically, and allows you to track your changes over time, create branches for different projects, and to revert to a previous state if you don't like the way a project is going. | |||
* '''{{OSWiki|Submitting code|alt=Submit code}}''' - Submit code - if you have a piece of source code (be it a fix or a new feature) submit the patches in a way that makes it easy for the Lindens to incorporate them into the source code. | * '''{{OSWiki|Submitting code|alt=Submit code}}''' - Submit code - if you have a piece of source code (be it a fix or a new feature) submit the patches in a way that makes it easy for the Lindens to incorporate them into the source code. | ||
** '''{{OSWiki|Crash Reports|alt=Crash Reports}}''' - Fix bugs - the easiest way to get involved as a developer is to start fixing bugs. The top 10 viewer crashes and the top 5 Mac crashes are listed. These are the most likely patches to get accepted | ** '''{{OSWiki|Crash Reports|alt=Crash Reports}}''' - Fix bugs - the easiest way to get involved as a developer is to start fixing bugs. The top 10 viewer crashes and the top 5 Mac crashes are listed. These are the most likely patches to get accepted | ||
** '''{{OSWiki|Implementing new features|alt=Implement new features}}''' - Implement new features - Of course, a really valuable way to contribute is to add a new feature. Try to work with the community and with Linden Lab in planning the feature before running off and implementing new things. Though we appreciate your hard work, we can't accept every new feature, since maintaining new features comes with a cost. Try thinking of ways to use APIs to make plugins, or perhaps propose new APIs to make the viewer more extensible, before adding new things to the core viewer. | ** '''{{OSWiki|Implementing new features|alt=Implement new features}}''' - Implement new features - Of course, a really valuable way to contribute is to add a new feature. Try to work with the community and with Linden Lab in planning the feature before running off and implementing new things. Though we appreciate your hard work, we can't accept every new feature, since maintaining new features comes with a cost. Try thinking of ways to use APIs to make plugins, or perhaps propose new APIs to make the viewer more extensible, before adding new things to the core viewer. | ||
* ''(obsolete'') '''[[Architecture Working Group]]''' - Participate in the working group Linden Lab has established to help forge the future protocols and architecture for Second Life. | |||
Latest revision as of 13:16, 6 July 2017
Ways to partcipate
- Download a test build - try downloading and testing out the latest version of the software.
- Communicate - Let us know what you think by email, on the forum, or IRC. If it's not working for you, try to get help there. If it is working for you, try helping someone who isn't having as much luck as you are.
- Get source and compile - Download and compile - even if you don't plan to develop, just the act of downloading and compiling can uncover problems. If the version you download doesn't build on your platform, file a bug.
- Developers are encouraged to complete the Second Life Viewer Contributor Agreement. Submissions to Snowglobe cannot be included in the official Second Life Viewer without this agreement in place.
- File and vet bugs - if you run into issues, look through the bug database and see if a bug has been filed. If so, vote for the issue to be fixed. If not, file the bug. Vetting bugs is just as important (if not more so) than filing bugs. We need to know whether each bug that's been filed is a problem for one person, or a problem for many. Try reproducing some of the bugs that have been filed, and see if they are problems for you. If you can't figure out how to reproduce the problem, make a comment on the bug, asking the person to describe their problem in more detail.
- File and refine feature requests - We're always looking for new ideas. Please let us know what you would like to see done. Also, features are more likely to get implemented if the description of the feature is clear. For a complicated feature, a link to a specification on the wiki is a great way to help flesh out the idea.
- Profile and optimize - If you're interested in improving the performance of the software, take a look at these notes on how to profile and optimize code.
- Create a version control repository - if you make extensive changes to the source download packages, it is easy to lose track of what files you changed, as well as remembering what you did and when. A version control repository keeps track of these file changes for you automatically, and allows you to track your changes over time, create branches for different projects, and to revert to a previous state if you don't like the way a project is going.
- Submit code - Submit code - if you have a piece of source code (be it a fix or a new feature) submit the patches in a way that makes it easy for the Lindens to incorporate them into the source code.
- Crash Reports - Fix bugs - the easiest way to get involved as a developer is to start fixing bugs. The top 10 viewer crashes and the top 5 Mac crashes are listed. These are the most likely patches to get accepted
- Implement new features - Implement new features - Of course, a really valuable way to contribute is to add a new feature. Try to work with the community and with Linden Lab in planning the feature before running off and implementing new things. Though we appreciate your hard work, we can't accept every new feature, since maintaining new features comes with a cost. Try thinking of ways to use APIs to make plugins, or perhaps propose new APIs to make the viewer more extensible, before adding new things to the core viewer.
- (obsolete) Architecture Working Group - Participate in the working group Linden Lab has established to help forge the future protocols and architecture for Second Life.