blackberry / community Goto Github PK

It might be useful to have a mechanism for folks to suggest new pages for the wiki. That creates connection with the community and also may help create useful pages earlier.

Weekly pass through the Forums?
Use Issues on the repo and suggest folks to "comment" to show support? (unfortunately this new Issues 2.0 does not have voting (nor priorities or ordering - see https://github.com/blog/831-issues-2-0-the-next-generation)

Create a variant of markdownify that will NOT insert the

around links so we can use Markdown in links in pages.

Do we want to keep the examples of pages in an "examples/" section of the gh-pages branch? in the master branch? or somewhere else?

Page for Gameplay wanted

Please create a new page for Warsaw so we can add information relevant to developers living close to the city

Pointer into BlackBerry JAM Community - https://bdsc.webapps.blackberry.com/devzone/jamcommunity/groups

Use Frogatto as an example of an OSS gaming engine

There should be a place to compile information, in an easily browsable matrix (or set of matrices), about all the RIM devices that developers may care about. This information is currently scattered around, between various self-compiled tables and product web pages, making it hard to find a central composite source of info.

Off the top of my head, I can think of the following compilations of device information that I've wanted or seen compiled from various sources:

• Devices vs. supported OS versions
• Devices vs. input form-factors (keypads, hot-keys, touchscreens, etc.)
• Devices vs. screen resolution / pixel density
• Devices vs. hardware features
• Localized standard key-bindings for common user/app functions, across the above
• Known issues with different devices

The idea is to not only have a simple device info database, but to also have a way to get at a cross-product-line view of useful information. This section could also link to code samples for programmatically categorizing devices with respect to the above, when possible.

Every toolchain has its share of bugs, gotchas, and workarounds. When we run into them, many of us either figure them out, or furiously search forums/blogs until we find solutions. Some are covered in the official documentation, some aren't, and some are just too obscure. We need a FAQ-like section where we can collect some of this information, mined from forums if necessary, allowing for running commentary on what works or doesn't work for people.

Another example of technology being in-flight.

links to Try-And-Buy as an example

Pointers into Android Runtime for BlackBerry

Dynamically generated.
Needs to follow hierarchy of layout

Need a consistent way to capture / lay out things like "See also:"

An example of a technology page: NFC

Do we want FAQ/ in a subsection?
Do we want people/ in a subsection?
Do we want ?

Example of technology being ported right now. Links, etc.

Point to QtCollator as an example of how to do collation efficiently

Do we deal with ambiguation like Wikipedia does? (two pages?)

Layout for people in the community.

Pages are possibly all under a people/ directory

Layout may not have a RHS column, and may mostly be based on the YAML variables

Talk with legal about using one of the Creative Commons license here

So far I've been using "_" to separate works, and I've capitalized Words.

We need to clarify that is the case and document it.

An example of a technology page

I'm still getting up-to-speed on Jekyll. Arrangements that seem ackward are:

• _config.yml - the 'force-prefix' property is used to adjust the URL path depending on whether the site is local or at GitHub. I could not find a property for 'site' that I could use (easily) to do that.
• A typical layout file will set a few variables, some using a capture tag, and then include a common include file. This is because I could not figure how to do something like {% include {{ left-file }} %}.

Search "button" is really just a stand-in for now. It neither looks correct, nor does it work.
It should do a google/bing search localized to the pages in the wiki.

Some layouts have a right column. That column should really be a frame insert, not a column.

The site needs a way to contain content for pre-BB10 development, since these devices will continue to be relevant for quite some time, and there's a lot of scattered know-how already out there to be compiled. At a high-level, this content may follow a similar structure as BB10 content, but it should be obvious to users of the site as to which they're looking at.

Pointer to new policy, and to clarification in Support Forum.

Markdown has support for "reference" links. It would be useful to refer to them within the YAML Front Matter in the pages.

Jekyll seems to process the markup (markdown in this case) separate from the templating. If YAML tags are included unmodified, then the content is not run through redcarpet/markdown. Using the "markdownify" filter helps but that filter knows nothing about the references.

One solution is to create a new filter that uses a well-known reference file - (something like common-refs)
Another, simpler and more transparent, approach is to move some "conventions" from YAML tags+template into the "prototype" of the example.

Still evaluating between the two options