Difference between revisions of "Participating"
Jump to navigation
Jump to search
| Line 5: | Line 5: | ||
* '''{{OSWiki|Downloading test builds|alt=Download a test build}}''' - try downloading a testing out the latest version of the software. | * '''{{OSWiki|Downloading test builds|alt=Download a test build}}''' - try downloading a testing out the latest version of the software. | ||
* '''{{OSWiki|Communication tools|alt=Communicate}}''' - Let us know what you think on 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|Communication tools|alt=Communicate}}''' - Let us know what you think on 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|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| | * '''{{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| | ** '''{{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 | |||
Revision as of 14:37, 13 June 2007
Ways to partcipate
- Download a test build - try downloading a testing out the latest version of the software.
- Communicate - Let us know what you think on 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.
- 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.
- 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.