Differences

This shows you the differences between two versions of the page.

--- dev:new_developer_wishlist [2012/05/18 13:03] – loriayre
+++ dev:new_developer_wishlist [2022/02/10 13:34] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
-====== Quicklinks to Contributions Made to the Developer Documentation Based on our Wish List Below ======
+====== Quicklinks to Contributions Pertinent to our Wish List Below ======
+  * This is our starting point: [[:contributing#code_contribution]]
-[[:EGDeveloperOverview|Evergreen Developer Overview]] (initial draft provided by Thomas Berezansky)
+  * Also see Using [[dev:git]]
+  * Also see Dan Scott's tutorial on developing the TPAC at [[http://bzr.coffeecode.net/2011/tpac_tutorial/]]
+  * New Stuff
+    * [[:EG_Developer_Overview|Evergreen Developer Overview]] (initial draft provided by Thomas Berezansky)
 ====== Wish List Items/Discussion ======
@@ Line 26: / Line 29: @@
           * Style Guide
       * Manual tests you can perform to test different parts of the system (the srfsh interface, testing javascript in Firefox with Firebug, command line, etc.)  (see tsbere document-in-making below)
+          * And when you can just refresh a page, when you have to restart apache, when you have to restart opensrf, when you have to run make again, etc.
   * **API Reference**
   * **Useful resources**
-  * See Dan Scott's information on developing the TPAC at [[http://bzr.coffeecode.net/2011/tpac_tutorial/]] - it does not yet dive
+  * See Dan Scott's information on developing the TPAC at [[http://bzr.coffeecode.net/2011/tpac_tutorial/]] - it does not yet dive into how we're loading up the context objects from Perl but is a suitably licensed starting point at least.
-into how we're loading up the context objects from Perl but is a suitably licensed starting point at least.
   * **Areas Claimed to Document**
@@ Line 53: / Line 56: @@
   * **Additional desiderata, from Scott Prater**
     * It would be nice if a list of required **libraries** and software and their versions were made available, not just packages.  It would be much easier to port Evergreen to a different OS, or a different release of a supported OS, if developers knew what software within a package was necessary.  Once you know the library or utility that's required, discovering which package contains it and installing it for a given OS is trivial.
-    * Change the formatting, fonts, etc. of the wiki.  Reading some of the wiki pages, especially the "Contributing" page, is a bit like reading the fine print of an insurance contract.  More white space, smaller chunks of text would help tremendously.  See http://guides.rubyonrails.org/getting_started.html[[http://guides.rubyonrails.org/getting_started.html|Rails Guides]] for an example of documentation that's easy-to-read.
+    * Change the formatting, fonts, etc. of the wiki.  Reading some of the wiki pages, especially the "Contributing" page, is a bit like reading the fine print of an insurance contract.  More white space, smaller chunks of text would help tremendously.  See [[http://guides.rubyonrails.org/getting_started.html|Rails Guides]] for an example of documentation that's easy-to-read.
     * Code formatting style guide.  Some formal rules on how code should be formatted would be great.  Configuration files for popular editors (vi, emacs, nano, bbedit, etc.) that developers could copy and use to automatically format the code for you according to the formal conventions would be even better (a second pass).