Difference between revisions of "Template talk:LSL Function"
Jump to navigation
Jump to search
(→TODO) |
|||
| Line 9: | Line 9: | ||
* #var:type collision between templates, causes errors in the documentation. Rename variable -- Half Done | * #var:type collision between templates, causes errors in the documentation. Rename variable -- Half Done | ||
* New hidden category sorting LSL topics by bug count. -- Easy (Done for functions) | * New hidden category sorting LSL topics by bug count. -- Easy (Done for functions) | ||
* Common Mistakes section? | * Common Mistakes section? | ||
* Disable category inclusion for requests? | * Disable category inclusion for requests? | ||
Revision as of 17:51, 8 March 2010
TODO
While this todo list is specific for LSL Functions, it doubles as the suggestion table for LSL Events, Constants and Conditionals.
- See Also-Examples should be moved into Examples section -- Will need better name.
- Split Issues into Issues and Bugs, put bugs into Caveats - Done for functions & constants.
- Rename Caveats to "Take Note" or "Be Aware"
- Promote Issues subsction into Notes. -- Easy
- JIRA Search link. In notes? -- Easy - done for functions & constants.
- #var:type collision between templates, causes errors in the documentation. Rename variable -- Half Done
- New hidden category sorting LSL topics by bug count. -- Easy (Done for functions)
- Common Mistakes section?
- Disable category inclusion for requests?
- Get/Set Caveat separation for sub-templates #var:caveats_set, #var:caveats_get, will aid in using the templates for constants. -- Tedious
- Change History section to a table? - Tedious. History section format and layout needs standardizing first.
- Generic: Setup bug counting in category thingy
- Constants: Normalize bug tables for PRIM_TEXTURE (it looks bad). Solve with embeddable caveats section Template with header & search links (I don't know why I haven't done it previously).
An item may live on the list for a long time because
- It's half baked. These are marked with question marks. Typically there are good reasons not to implement them, there are many ways of implementing it, or there isn't a pressing need.
- It would take a lot of work to implement. Some items may involve editing hundreds of pages.
Changes to the uniform style are typically tried out on the Events first, there aren't that many of them and making multiple changes doesn't hurt the wiki as much as making a change to either Functions or Constants. Conditionals is often forgotten during the update cycle.