diff options
| author | Andrew Manning <tamanning@zoho.com> | 2017-02-12 13:59:17 -0500 |
|---|---|---|
| committer | Andrew Manning <tamanning@zoho.com> | 2017-02-12 13:59:17 -0500 |
| commit | baf612bd598aaeb78b8cc92e958912f76d4d3e46 (patch) | |
| tree | b9777cd8468d215b8c544cc727e7de1088611e55 /doc | |
| parent | f3490440b43d93701e54b0326ce039e2242b3f5c (diff) | |
| download | volse-hubzilla-baf612bd598aaeb78b8cc92e958912f76d4d3e46.tar.gz volse-hubzilla-baf612bd598aaeb78b8cc92e958912f76d4d3e46.tar.bz2 volse-hubzilla-baf612bd598aaeb78b8cc92e958912f76d4d3e46.zip | |
Reformat code of conduct for developers and integrate.
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/contributor/covenant.html | 106 | ||||
| -rw-r--r-- | doc/developer/covenant.bb | 47 | ||||
| -rw-r--r-- | doc/developer/developer_guide.bb | 422 | ||||
| -rw-r--r-- | doc/developer/developer_guide_original.md (renamed from doc/developer/developer_guide.md) | 0 | ||||
| -rw-r--r-- | doc/to_do_code.bb | 42 | ||||
| -rw-r--r-- | doc/to_do_doco.md | 31 | ||||
| -rw-r--r-- | doc/toc.html | 1 |
7 files changed, 470 insertions, 179 deletions
diff --git a/doc/contributor/covenant.html b/doc/contributor/covenant.html deleted file mode 100644 index 4facac24e..000000000 --- a/doc/contributor/covenant.html +++ /dev/null @@ -1,106 +0,0 @@ -<!DOCTYPE html> - -<html lang="en"> -<head> - <meta charset="utf-8"/> - <title>Contributor Covenant 1.4.0</title> - <style> - body { - font-family: monospace; - padding: 4em; - } - a { - color: #990000; - } - </style> - <link rel="alternate" hreflang="de" href="version/1/3/0/de/" /> - <link rel="alternate" hreflang="es" href="version/1/4/es/" /> - <link rel="alternate" hreflang="fr" href="version/1/3/0/fr/" /> - <link rel="alternate" hreflang="hu" href="version/1/3/0/hu/" /> - <link rel="alternate" hreflang="it" href="version/1/3/0/it/" /> - <link rel="alternate" hreflang="ja" href="version/1/3/0/ja/" /> - <link rel="alternate" hreflang="pl" href="version/1/4/pl/" /> - <link rel="alternate" hreflang="pt" href="version/1/3/0/pt/" /> - <link rel="alternate" hreflang="pt" href="version/1/3/0/pt_br/" /> - <link rel="alternate" hreflang="ru" href="version/1/3/0/ru/" /> - <link rel="alternate" hreflang="sl" href="version/1/4/sl/" /> - <link rel="alternate" hreflang="uk" href="version/1/4/uk/" /> -</head> - -<body> - -<h1>Contributor Covenant Code of Conduct</h1> - -<h2>Our Pledge</h2> - -<p>In the interest of fostering an open and welcoming environment, we as -contributors and maintainers pledge to making participation in our project and -our community a harassment-free experience for everyone, regardless of age, body -size, disability, ethnicity, gender identity and expression, level of experience, -nationality, personal appearance, race, religion, or sexual identity and -orientation.</p> - -<h2>Our Standards</h2> - -<p>Examples of behavior that contributes to creating a positive environment -include:</p> - -<ul> - <li>Using welcoming and inclusive language</li> - <li>Being respectful of differing viewpoints and experiences</li> - <li>Gracefully accepting constructive criticism</li> - <li>Focusing on what is best for the community</li> - <li>Showing empathy towards other community members</li> -</ul> - -<p>Examples of unacceptable behavior by participants include:</p> - -<ul> - <li>The use of sexualized language or imagery and unwelcome sexual attention or advances</li> - <li>Trolling, insulting/derogatory comments, and personal or political attacks</li> - <li>Public or private harassment</li> - <li>Publishing others' private information, such as a physical or electronic address, without explicit permission</li> - <li>Other conduct which could reasonably be considered inappropriate in a professional setting</li> -</ul> - -<h2>Our Responsibilities</h2> - -<p>Project maintainers are responsible for clarifying the standards of acceptable -behavior and are expected to take appropriate and fair corrective action in -response to any instances of unacceptable behavior.</p> - -<p>Project maintainers have the right and responsibility to remove, edit, or -reject comments, commits, code, wiki edits, issues, and other contributions -that are not aligned to this Code of Conduct, or to ban temporarily or -permanently any contributor for other behaviors that they deem inappropriate, -threatening, offensive, or harmful.</p> - -<h2>Scope</h2> - -<p>This Code of Conduct applies both within project spaces and in public spaces -when an individual is representing the project or its community. Examples of -representing a project or community include using an official project e-mail -address, posting via an official social media account, or acting as an appointed -representative at an online or offline event. Representation of a project may be -further defined and clarified by project maintainers.</p> - -<h2>Enforcement</h2> - -<p>Instances of abusive, harassing, or otherwise unacceptable behavior may be -reported by contacting the project team at project@hubzilla.org. All -complaints will be reviewed and investigated and will result in a response that -is deemed necessary and appropriate to the circumstances. The project team is -obligated to maintain confidentiality with regard to the reporter of an incident. -Further details of specific enforcement policies may be posted separately.</p> - -<p>Project maintainers who do not follow or enforce the Code of Conduct in good -faith may face temporary or permanent repercussions as determined by other -members of the project's leadership.</p> - -<h2>Attribution</h2> - -<p>This Code of Conduct is adapted from the <a href="http://contributor-covenant.org">Contributor Covenant</a>, version 1.4, -available at <a href="http://contributor-covenant.org/version/1/4/">http://contributor-covenant.org/version/1/4</a>.</p> - -</body> -</html> diff --git a/doc/developer/covenant.bb b/doc/developer/covenant.bb new file mode 100644 index 000000000..70e06762c --- /dev/null +++ b/doc/developer/covenant.bb @@ -0,0 +1,47 @@ +[size=large]Contributor Covenant Code of Conduct[/size] + +[h3]Our Pledge[/h3] + +In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. + +[h3]Our Standards[/h3] + +Examples of behavior that contributes to creating a positive environment +include: + +[list] + [*]Using welcoming and inclusive language + [*]Being respectful of differing viewpoints and experiences + [*]Gracefully accepting constructive criticism + [*]Focusing on what is best for the community + [*]Showing empathy towards other community members +[/list] + +Examples of unacceptable behavior by participants include: + +[list] + [*]The use of sexualized language or imagery and unwelcome sexual attention or advances + [*]Trolling, insulting/derogatory comments, and personal or political attacks + [*]Public or private harassment + [*]Publishing others' private information, such as a physical or electronic address, without explicit permission + [*]Other conduct which could reasonably be considered inappropriate in a professional setting +[/list] + +[h3]Our Responsibilities[/h3] + +Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. + +[h3]Scope[/h3] + +This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. + +[h3]Enforcement[/h3] + +Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at project@hubzilla.org. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. + +Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. + +[h3]Attribution[/h3] + +This Code of Conduct is adapted from the [url="http://contributor-covenant.org"]Contributor Covenant[/url], version 1.4, available at [url="http://contributor-covenant.org/version/1/4/"]http://contributor-covenant.org/version/1/4[/url]. + diff --git a/doc/developer/developer_guide.bb b/doc/developer/developer_guide.bb new file mode 100644 index 000000000..6357ed56c --- /dev/null +++ b/doc/developer/developer_guide.bb @@ -0,0 +1,422 @@ +[h3]Who is a $Projectname developer? Should I read this?[/h3] + +Anyone who contributes to making $Projectname better is a developer. There are many different and important ways you can contribute to this amazing technology, [i]even if you do not know how to write code[/i]. The software itself is only a part of the $Projectname project. You can contribute by +[list] +[*] translating text to your language so that people around the world have the opportunity to use $Projectname +[*] promoting $Projectname and spreading awareness of the platform through blog posts, articles, and word-of-mouth +[*] creating artwork and graphics for project assets such as icons and marketing material +[*] supporting project infrastructure like the project website and demo servers +[/list] +[i]Software[/i] developers are of course welcomed; there are so many great ideas to implement and not enough people to make them all a reality! The $Projectname code base is an advanced and mature system, but the platform is still very flexible and responsive to new ideas. + +We're pretty relaxed when it comes to developers. We don't have a lot of rules. Some of us are over-worked and if you want to help we're happy to let you help. That said, attention to a few guidelines will make the process smoother and make it easier to work together. All developers are expected to abide by our [zrl=[baseurl]/help/developer/covenant]code of conduct[/zrl]. We have developers from across the globe with different abilities and different cultural backgrounds and different levels of patience. Our primary rule is to respect others. Sometimes this is hard and sometimes we have very different opinions of how things should work, but if everybody makes an effort, we'll get along just fine. + +This document will help you get started learning and contributing to $Projectname. + +[h3]Versioning system[/h3] + +The versioning system is similar to the popular semantic versioning but less stringent. Given x.y.z, x changes yearly. y changes for "stable" monthly builds, and z increments when there are interface changes. We maintain our date and build numbers for medium grain version control (commits within a certain date range) and of course git revs for fine grained control. + +[h3]Git repository branches[/h3] + +There are two official branches of the $Projectname git repo. +[list] +[*] The stable version is maintained on the [*]*master** branch. The latest commit in this branch is considered to be suitable for production hubs. +[*] Experimental development occurs on the **dev** branch, which is merged into **master** when it is deemed tested and stable enough. +[/list] + +[h3]Developer tools and workflows[/h3] + +[h4]Hub Snapshots[/h4] + +The [url=/help/admin/hub_snapshots]hub snapshots[/url] page provides instructions and scripts for taking complete snapshots of a hub to support switching between consistent and completely known states. This is useful to prevent situations where the content or database schema might be incompatible with the code. + +[h3]Translations[/h3] + +Our translations are managed through Transifex. If you wish to help out translating $Projectname to another language, sign up on transifex.com, visit [url=https://www.transifex.com/Friendica/red-matrix/]Transifex[/url] and request to join one of the existing language teams or create a new one. Notify one of the core developers when you have a translation update which requires merging, or ask about merging it yourself if you're comfortable with git and PHP. We have a string file called 'messages.po' which is gettext compliant and a handful of email templates, and from there we automatically generate the application's language files. + +[h4]Translation Process[/h4] + +The strings used in the UI of $Projectname is translated at [url=https://www.transifex.com/Friendica/red-matrix/]Transifex[/url] and then +included in the git repository at github. If you want to help with translation +for any language, be it correcting terms or translating $Projectname to a +currently not supported language, please register an account at transifex.com +and contact the Redmatrix translation team there. + +Translating $Projectname is simple. Just use the online tool at transifex. If you +don't want to deal with git & co. that is fine, we check the status of the +translations regularly and import them into the source tree at github so that +others can use them. + +We do not include every translation from transifex in the source tree to avoid +a scattered and disturbed overall experience. As an uneducated guess we have a +lower limit of 50% translated strings before we include the language. This +limit is judging only by the amount of translated strings under the assumption +that the most prominent strings for the UI will be translated first by a +translation team. If you feel your translation useable before this limit, +please contact us and we will probably include your teams work in the source +tree. + +If you want to get your work into the source tree yourself, feel free to do so +and contact us with and question that arises. The process is simple and +$Projectname ships with all the tools necessary. + +The location of the translated files in the source tree is + /view/LNG-CODE/ +where LNG-CODE is the language code used, e.g. de for German or fr for French. +For the email templates (the *.tpl files) just place them into the directory +and you are done. The translated strings come as a "hmessages.po" file from +transifex which needs to be translated into the PHP file $Projectname uses. To do +so, place the file in the directory mentioned above and use the "po2php" +utility from the util directory of your $Projectname installation. + +Assuming you want to convert the German localization which is placed in +view/de/hmessages.po you would do the following. + +1. Navigate at the command prompt to the base directory of your + $Projectname installation + +2. Execute the po2php script, which will place the translation + in the hstrings.php file that is used by $Projectname. + + $> php util/po2php.php view/de/hmessages.po + + The output of the script will be placed at view/de/hstrings.php where + froemdoca os expecting it, so you can test your translation mmediately. + +3. Visit your $Projectname page to check if it still works in the language you + just translated. If not try to find the error, most likely PHP will give + you a hint in the log/warnings.about the error. + + For debugging you can also try to "run" the file with PHP. This should + not give any output if the file is ok but might give a hint for + searching the bug in the file. + + $> php view/de/hstrings.php + +4. commit the two files with a meaningful commit message to your git + repository, push it to your fork of the $Projectname repository at github and + issue a pull request for that commit. + +[h4]Utilities[/h4] + +Additional to the po2php script there are some more utilities for translation +in the "util" directory of the $Projectname source tree. If you only want to +translate $Projectname into another language you wont need any of these tools most +likely but it gives you an idea how the translation process of $Projectname +works. + +For further information see the utils/README file. + +[h4]Known Problems[/h4] + +* $Projectname uses the language setting of the visitors browser to determain the + language for the UI. Most of the time this works, but there are some known + quirks. +* the early translations are based on the friendica translations, if you + some rough translations please let us know or fix them at Transifex. + +[h3]To-be-organized information[/h3] + +[b]Here is how you can join us.[/b] + +First, get yourself a working git package on the system where you will be +doing development. + +Create your own github account. + +You may fork/clone the Red repository from [url=https://github.com/redmatrix/hubzilla.git]https://github.com/redmatrix/hubzilla.git[/url]. + +Follow the instructions provided here: [url=http://help.github.com/fork-a-repo/]Fork a Repo[/url] +to create and use your own tracking fork on github + +Then go to your github page and create a "Pull request" when you are ready +to notify us to merge your work. + + +**Important** + +Please pull in any changes from the project repository and merge them with your work **before** issuing a pull request. We reserve the right to reject any patch which results in a large number of merge conflicts. This is especially true in the case of language translations - where we may not be able to understand the subtle differences between conflicting versions. + +Also - **test your changes**. Don't assume that a simple fix won't break something else. If possible get an experienced Red developer to review the code. + + +**Licensing** + +All code contributed to the project falls under the MIT license, unless otherwise specified. We will accept third-party code which falls under MIT, BSD and LGPL, but copyleft licensing (GPL, and AGPL) is only permitted in addons. It must be possible to completely remove the GPL (copyleft) code from the main project without breaking anything. + +**Coding Style** + +In the interests of consistency we adopt the following code styling. We may accept patches using other styles, but where possible please try to provide a consistent code style. We aren't going to argue or debate the merits of this style, and it is irrelevant what project 'xyz' uses. This is not project 'xyz'. This is a baseline to try and keep the code readable now and in the future. + +* All comments should be in English. + +* We use doxygen to generate documentation. This hasn't been consistently applied, but learning it and using it are highly encouraged. + +* Indentation is accomplished primarily with tabs using a tab-width of 4. + +* String concatenation and operators should be separated by whitespace. e.g. "$foo = $bar . 'abc';" instead of "$foo=$bar.'abc';" + +* Generally speaking, we use single quotes for string variables and double quotes for SQL statements. "Here documents" should be avoided. Sometimes using double quoted strings with variable replacement is the most efficient means of creating the string. In most cases, you should be using single quotes. + +* Use whitespace liberally to enhance readability. When creating arrays with many elements, we will often set one key/value pair per line, indented from the parent line appropriately. Lining up the assignment operators takes a bit more work, but also increases readability. + +* Generally speaking, opening braces go on the same line as the thing which opens the brace. They are the last character on the line. Closing braces are on a line by themselves. + + +**File system layout:** + +[addon] optional addons/plugins + +[boot.php] Every process uses this to bootstrap the application structure + +[doc] Help Files + +[images] core required images + +[include] The "model" in MVC - (back-end functions), also contains PHP "executables" for background processing + +[index.php] The front-end controller for web access + +[install] Installation and upgrade files and DB schema + +[library] Third party modules (must be license compatible) + +[mod] Controller modules based on URL pathname (e.g. #^[url=http://sitename/foo]http://sitename/foo[/url] loads mod/foo.php) + +[mod/site/] site-specific mod overrides, excluded from git + +[util] translation tools, main English string database and other miscellaneous utilities + +[version.inc] contains current version (auto-updated via cron for the master repository and distributed via git) + +[view] theming and language files + +[view/(css,js,img,php,tpl)] default theme files + +[view/(en,it,es ...)] language strings and resources + +[view/theme/] individual named themes containing (css,js,img,php,tpl) over-rides + +**The Database:** + + +| Table | Description | +|-------------------------|--------------------------------------------------------| +| abconfig | contact table, replaces Friendica 'contact' | +| abook | | +| account | service provider account | +| addon | | +| addressbookchanges | | +| addressbooks | | +| app | | +| atoken | | +| attach | | +| auth_codes | | +| cache | | +| cal | | +| calendarchanges | | +| calendarinstances | | +| calendarobjects | | +| calendars | | +| calendarsubscriptions | | +| cards | | +| channel | | +| chat | | +| chatpresence | | +| chatroom | | +| clients | | +| config | | +| conv | | +| dreport | | +| event | | +| group_member | | +| groupmembers | | +| groups | | +| hook | | +| hubloc | | +| iconfig | | +| issue | | +| item | | +| item_id | | +| likes | | +| locks | | +| mail | | +| menu | | +| menu_item | | +| notify | | +| obj | | +| outq | | +| pconfig | personal (per channel) configuration storage | +| photo | | +| poll | | +| poll_elm | | +| principals | | +| profdef | | +| profext | | +| profile | | +| profile_check | | +| propertystorage | | +| register | | +| schedulingobjects | | +| session | | +| shares | | +| sign | | +| site | | +| source | | +| sys_perms | | +| term | | +| tokens | | +| updates | | +| users | | +| verify | | +| vote | | +| xchan | | +| xchat | | +| xconfig | | +| xign | | +| xlink | | +| xperm | | +| xprof | | +| xtag | | + + + * abook - contact table, replaces Friendica 'contact' + * account - service provider account + * addon - registered plugins + * app - peronal app data + * attach - file attachments + * auth_codes - OAuth usage + * cache - OEmbed cache + * channel - replaces Friendica 'user' + * chat - chat room content + * chatpresence - channel presence information for chat + * chatroom - data for the actual chat room + * clients - OAuth usage + * config - main configuration storage + * conv - Diaspora private messages + * event - Events + * fcontact - friend suggestion stuff + * ffinder - friend suggestion stuff + * fserver - obsolete + * fsuggest - friend suggestion stuff + * groups - privacy groups + * group_member - privacy groups + * hook - plugin hook registry + * hubloc - Red location storage, ties a location to an xchan + * item - posts + * item_id - other identifiers on other services for posts + * likes - likes of 'things' + * mail - private messages + * menu - channel menu data + * menu_item - items uses by channel menus + * notify - notifications + * notify-threads - need to factor this out and use item thread info on notifications + * obj - object data for things (x has y) + * outq - output queue + * pconfig - personal (per channel) configuration storage + * photo - photo storage + * poll - data for polls + * poll_elm - data for poll elements + * profdef - custom profile field definitions + * profext - custom profile field data + * profile - channel profiles + * profile_check - DFRN remote auth use, may be obsolete + * register - registrations requiring admin approval + * session - web session storage + * shares - shared item information + * sign - Diaspora signatures. To be phased out. + * site - site table to find directory peers + * source - channel sources data + * spam - unfinished + * sys_perms - extensible permissions for the sys channel + * term - item taxonomy (categories, tags, etc.) table + * tokens - OAuth usage + * updates - directory sync updates + * verify - general purpose verification structure + * vote - vote data for polls + * xchan - replaces 'gcontact', list of known channels in the universe + * xchat - bookmarked chat rooms + * xconfig - as pconfig but for channels with no local account + * xlink - "friends of friends" linkages derived from poco + * xprof - if this hub is a directory server, contains basic public profile info of everybody in the network + * xtag - if this hub is a directory server, contains tags or interests of everybody in the network + + +**How to theme $Projectname** + +This is a short documentation on what I found while trying to modify $Projectname's appearance. + +First, you'll need to create a new theme. This is in /view/theme, and I chose to copy 'redbasic' since it's the only available for now. Let's assume I named it . + +Oh, and don't forget to rename the _init function in /php/theme.php to be _init() instead of redbasic_init(). + +At that point, if you need to add javascript or css files, add them to /js or /css, and then "register" them in _init() through head_add_js('file.js') and head_add_css('file.css'). + +Now you'll probably want to alter a template. These can be found in in /view/tpl OR view//tpl. All you should have to do is copy whatever you want to tweak from the first place to your theme's own tpl directory. + + +We're pretty relaxed when it comes to developers. We don't have a lot of rules. Some of us are over-worked and if you want to help we're happy to let you help. That said, attention to a few guidelines will make the process smoother and make it easier to work together. We have developers from across the globe with different abilities and different cultural backgrounds and different levels of patience. Our primary rule is to respect others. Sometimes this is hard and sometimes we have very different opinions of how things should work, but if everybody makes an effort, we'll get along just fine. + +**Here is how you can join us.** + +First, get yourself a working git package on the system where you will be +doing development. + +Create your own github account. + +You may fork/clone the Red repository from [url=https://github.com/redmatrix/hubzilla.git]https://github.com/redmatrix/hubzilla.git[/url] + +Follow the instructions provided here: [url=http://help.github.com/fork-a-repo/]http://help.github.com/fork-a-repo/[/url] +to create and use your own tracking fork on github + +Then go to your github page and create a "Pull request" when you are ready +to notify us to merge your work. + +**Translations** + +Our translations are managed through Transifex. If you wish to help out translating the $Projectname to another language, sign up on transifex.com, visit [url=https://www.transifex.com/Friendica/red-matrix/]https://www.transifex.com/Friendica/red-matrix/[/url] and request to join one of the existing language teams or create a new one. Notify one of the core developers when you have a translation update which requires merging, or ask about merging it yourself if you're comfortable with git and PHP. We have a string file called 'messages.po' which is gettext compliant and a handful of email templates, and from there we automatically generate the application's language files. + + +**Important** + +Please pull in any changes from the project repository and merge them with your work **before** issuing a pull request. We reserve the right to reject any patch which results in a large number of merge conflicts. This is especially true in the case of language translations - where we may not be able to understand the subtle differences between conflicting versions. + +Also - **test your changes**. Don't assume that a simple fix won't break something else. If possible get an experienced Red developer to review the code. + +Further documentation can be found at the Github wiki pages at: [url=https://github.com/friendica/red/wiki]https://github.com/friendica/red/wiki[/url] + +**Licensing** + +All code contributed to the project falls under the MIT license, unless otherwise specified. We will accept third-party code which falls under MIT, BSD and LGPL, but copyleft licensing (GPL, and AGPL) is only permitted in addons. It must be possible to completely remove the GPL (copyleft) code from the main project without breaking anything. + +**Concensus Building** + +Code changes which fix an obvious bug are pretty straight-forward. For instance if you click "Save" and the thing you're trying to save isn't saved, it's fairly obvious what the intended behaviour should be. Often when developing feature requests, it may affect large numbers of community members and it's possible that other members of the community won't agree with the need for the feature, or with your proposed implementation. They may not see something as a bug or a desirable feature. + +We encourage consensus building within the community when it comes to any feature which might be considered controversial or where there isn't unanimous decision that the proposed feature is the correct way to accomplish the task. The first place to pitch your ideas is to [url=https://zothub.com/channel/one]Channel One[/url]. Others may have some input or be able to point out facets of your concept which might be problematic in our environment. But also, you may encounter opposition to your plan. This doesn't mean you should stop and/or ignore the feature. Listen to the concerns of others and try and work through any implementation issues. + +There are places where opposition cannot be resolved. In these cases, please consider making your feature **optional** or non-default behaviour that must be specifically enabled. This technique can often be used when a feature has significant but less than unanimous support. Those who desire the feature can turn it on and those who don't want it - will leave it turned off. + +If a feature uses other networks or websites and or is only seen as desirable by a small minority of the community, consider making the functionality available via an addon or plugin. Once again, those who don't desire the feature won't need to install it. Plugins are relatively easy to create and "hooks" can be easily added or modified if the current hooks do not do what is needed to allow your plugin to work. + + +**Coding Style** + +In the interests of consistency we adopt the following code styling. We may accept patches using other styles, but where possible please try to provide a consistent code style. We aren't going to argue or debate the merits of this style, and it is irrelevant what project 'xyz' uses. This is not project 'xyz'. This is a baseline to try and keep the code readable now and in the future. + +* All comments should be in English. + +* We use doxygen to generate documentation. This hasn't been consistently applied, but learning it and using it are highly encouraged. + +* Indentation is accomplished primarily with tabs using a tab-width of 4. + +* String concatenation and operators should be separated by whitespace. e.g. "$foo = $bar . 'abc';" instead of "$foo=$bar.'abc';" + +* Generally speaking, we use single quotes for string variables and double quotes for SQL statements. "Here documents" should be avoided. Sometimes using double quoted strings with variable replacement is the most efficient means of creating the string. In most cases, you should be using single quotes. + +* Use whitespace liberally to enhance readability. When creating arrays with many elements, we will often set one key/value pair per line, indented from the parent line appropriately. Lining up the assignment operators takes a bit more work, but also increases readability. + +* Generally speaking, opening braces go on the same line as the thing which opens the brace. They are the last character on the line. Closing braces are on a line by themselves. + +* Some functions take arguments in argc/argv style like main() in C or function args in bash or Perl. Urls are broken up within a module. e.g, given "http://example.com/module/arg1/arg2", then $this->argc will be 3 (integer) and $this->argv will contain: [0] => 'module', [1] => 'arg1', [2] => 'arg2'. There will always be one argument. If provided a naked domain URL, $this->argv[0] is set to "home".
\ No newline at end of file diff --git a/doc/developer/developer_guide.md b/doc/developer/developer_guide_original.md index fa50de8a1..fa50de8a1 100644 --- a/doc/developer/developer_guide.md +++ b/doc/developer/developer_guide_original.md diff --git a/doc/to_do_code.bb b/doc/to_do_code.bb deleted file mode 100644 index b1c4923b1..000000000 --- a/doc/to_do_code.bb +++ /dev/null @@ -1,42 +0,0 @@ -[b]Project Code To-Do List[/b]
-
-We need much more than this, but here are areas where developers can help. Please edit this page when items are finished. Another place for developers to start is with the issues list.
-
-[li]Documentation - see Red Documentation Project To-Do List[/li]
-[li]Include TOS link in registration/verification email[/li]
-[li]Auto preview posts/comments (configurable timer kicks in the preview if not 0)[/li]
-[li]SAML 2.0 and OpenID Connect provider functionality[/li]
-[li]relmeauth (aka indieauth) support[/li]
-[li]Create bug tracker module[/li]
-[li]Filing posts - provide a dropdown menu integrated with the 'post actions menu'[/li]
-[li]translation plugins - moses or apertium[/li]
-[li]plugins - provide 'disable' which is softer than 'uninstall' for those plugins which create additional DB tables[/li]
-[li]Infinite scroll improvements (i.e. embedded page links) see http://scrollsample.appspot.com/items [/li]
-[li]Finish the anti-spam bayesian engine[/li]
-[li]implement an email permission denied bounce message from the sys channel[/li]
-[li]provide a way for xchans with a certain network type to upgrade (unknown to rss, rss to statusnet, friendica-over-diaspora to friendica, for instance) based on new knowledge and/or redmatrix ability[/li]
-[li]Integrate the "open site" list with the register page[/li]
-[li]Support comments and member notes on documentation pages (to achieve an effect similar to php.net)[/li]
-[li]Support comments on webpages[/li]
-[li]Write more webpage layouts[/li]
-[li]Write more webpage widgets[/li]
-[li]restricted access OAuth clients[/li]
-[li](Advanced) create a UI for building Comanche pages[/li]
-[li](less advanced) create a way to preview Comanche results on a preview page while editing on another page[/li]
-[li]External post connectors - create standard interface[/li]
-[li]External post connectors, add popular services[/li]
-[li]service classes - provide a pluggable subscription payment gateway for premium accounts[/li]
-[li]service classes - account overview page showing resources consumed by channel. With special consideration this page can also be accessed at a meta level by the site admin to drill down on problematic accounts/channels.[/li]
-[li]Uploads - integrate #^[url=https://github.com/blueimp/jQuery-File-Upload]https://github.com/blueimp/jQuery-File-Upload[/url][/li]
-[li]API extensions, for Twitter API - search, friending, threading. For Red API, lots of stuff[/li]
-[li]Import channel from Diaspora/Friendica (Diaspora partially done)[/li]
-[li]MediaGoblin photo "crosspost" connector[/li]
-[li]provide a visual editor[/li]
-[li]Create mobile clients for the top platforms - which involves extending the API so that we can do stuff far beyond the current crop of Twitter/Statusnet clients. Ditto for mobile themes. We can probably use something like the Friendica Android app as a base to start from.[/li]
-[li]Implement owned and exchangeable "things".[/li]
-[li]Family Account creation - using service classes (an account holder can create a certain number of sub-accounts which are all tied to their subscription - if the subscription lapses they all go away).[/li]
-
-
-In many cases some of the work has already been started and code exists so that you needn't start from scratch. Please contact one of the developer channels like Channel One (one@zothub.com) before embarking and we can tell you what we already have and provide some insights on how we envision these features fitting together.
-
-Return to the [url=[baseurl]/help/main]Main documentation page[/url]
diff --git a/doc/to_do_doco.md b/doc/to_do_doco.md deleted file mode 100644 index 018b9efa2..000000000 --- a/doc/to_do_doco.md +++ /dev/null @@ -1,31 +0,0 @@ -# Documentation To-Do List #
-
-## How to contribute documentation ##
-
-Documentation files are in */doc*.
-
-When help is first accessed, the file loaded is *main.bb*. That file contains case sensitive links without an extension. The extensions is added automatically if the file is found, first *.md* then *.bb*.
-
-For translating documentation, create a directory in */doc* named by the language code, copy the files and translate the content.
-
-## Documentation we need to write ##
-
-* Database schema detailed descriptions
-
-* Complete plugin hook documentation
-
-* API documentation
-
-* Function and code documentation (doxygen)
-
-* New Member guide
-
-* "Extra Feature" reference, description of each
-
-* Detailed Personal Settings Documentation
-
-* Administration Guide (post-install)
-
-* Administration Guide (pre-install)
-
-#include doc/macros/main_footer.bb;
diff --git a/doc/toc.html b/doc/toc.html index 851f356e6..3581254e3 100644 --- a/doc/toc.html +++ b/doc/toc.html @@ -49,6 +49,7 @@ <div id="developers" class="panel-collapse collapse in"> <ul class="list-group"> <li class="doco-list-group-item"><a href="/help/developer/developer_guide">Guide</a></li> + <li class="doco-list-group-item"><a href="/help/developer/covenant">Code of Conduct</a></li> <li class="doco-list-group-item"><a href="/help/developer/zot_protocol">Zot Protocol</a></li> <li class="doco-list-group-item"><a href="/help/developer/api_zot">Zot API</a></li> </ul> |