Triaging

Jump to bottomEditNew page
Thomas E Enebo edited this page Aug 20, 2015 · 2 revisions

For those people interested in helping to triage JRuby issues, then this page will help you get rolling...

Initial Triage

First thing to consider is the quality of the issue (see JRubyBugReportingStyleGuide). If someone is not providing enough info or their reproduction is too large then you can follow up as a comment and ask them for more info. PLEASE NOTE: Every issue report we receive we should treat as a gift. Please treat the reporter in as pleasant of a way as possible. We want them to keep reporting issues and potentially get more involved in our project.

Another important aspect of triaging an issue is which compatibility level is the issue for? Is someone reporting a Ruby 2.2 issue against JRuby 1.7.22 in Ruby 1.9.3 mode? Are they reporting against 2.2 and JRuby 9k, but the compatibility issue has existed since Ruby 1.8.7? Narrow down which Ruby release the bug is valid for and then mark the labels 'JRuby 1.7' and/or 'JRuby 9000'. In a comment specify which versions you tracked the problem back to (e.g. "I can confirm this behavior changed in 1.8.7").

Highly recommended is to use RVM to get each significant release (1.8.7, 1.9.3, 2.0, 2.2.x) and then set up aliases like:

alias mri22='rvm 2.2.2 do ruby'alias mri20='rvm 2.0.0 do ruby'alias mri19='rvm 1.9 do ruby'alias mri18='rvm 1.8.7 do ruby'

Then you can simply run scripts:

mri19 -e '1/ 1.0'

Completing An Issue

Once an issue has been fixed or you determine that the issue is not valid you should mark a milestone in addition to closing the issue.

For issues which are duplicate or invalid you can mark as 'Invalid or Duplicate'. If an issue was deemed not fixable then mark it as 'Wont Fix'. If the issue is not tied to any particular release then mark it as 'Non-Release'.

For issues which have been corrected then there are two rules. First if the issue only affects a single support branch (e.g. only fixes a Ruby 1.8.7 problem on JRuby 1.7.x) then mark it against the current JRuby 1.7 point release (e.g. 1.7.22). If it applies to both release branches then also mark it against the older support branch (e.g. 1.7.22 vs 9.0.1.0). We only do this because github does not support multiple milestone selection at this time. Once we do then we should mark both point releases.

Add a custom sidebar

Clone this wiki locally

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
Triaging
Jump to bottomEditNew page

Thomas E Enebo edited this page Aug 20, 2015
·
2 revisions
For those people interested in helping to triage JRuby issues, then this page will help you get rolling...
Initial Triage
First thing to consider is the quality of the issue (see JRubyBugReportingStyleGuide). If someone is not providing enough info or their reproduction is too large then you can follow up as a comment and ask them for more info. PLEASE NOTE: Every issue report we receive we should treat as a gift. Please treat the reporter in as pleasant of a way as possible. We want them to keep reporting issues and potentially get more involved in our project.
Another important aspect of triaging an issue is which compatibility level is the issue for? Is someone reporting a Ruby 2.2 issue against JRuby 1.7.22 in Ruby 1.9.3 mode? Are they reporting against 2.2 and JRuby 9k, but the compatibility issue has existed since Ruby 1.8.7? Narrow down which Ruby release the bug is valid for and then mark the labels 'JRuby 1.7' and/or 'JRuby 9000'. In a comment specify which versions you tracked the problem back to (e.g. "I can confirm this behavior changed in 1.8.7").
Highly recommended is to use RVM to get each significant release (1.8.7, 1.9.3, 2.0, 2.2.x) and then set up aliases like:
alias mri22='rvm 2.2.2 do ruby'alias mri20='rvm 2.0.0 do ruby'alias mri19='rvm 1.9 do ruby'alias mri18='rvm 1.8.7 do ruby'
Then you can simply run scripts:
mri19 -e '1/ 1.0'
Completing An Issue
Once an issue has been fixed or you determine that the issue is not valid you should mark a milestone in addition to closing the issue.
For issues which are duplicate or invalid you can mark as 'Invalid or Duplicate'. If an issue was deemed not fixable then mark it as 'Wont Fix'. If the issue is not tied to any particular release then mark it as 'Non-Release'.
For issues which have been corrected then there are two rules. First if the issue only affects a single support branch (e.g. only fixes a Ruby 1.8.7 problem on JRuby 1.7.x) then mark it against the current JRuby 1.7 point release (e.g. 1.7.22). If it applies to both release branches then also mark it against the older support branch (e.g. 1.7.22 vs 9.0.1.0). We only do this because github does not support multiple milestone selection at this time. Once we do then we should mark both point releases.
 Add a custom sidebar

Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Triaging
Jump to bottomEditNew page

Thomas E Enebo edited this page Aug 20, 2015
·
2 revisions
For those people interested in helping to triage JRuby issues, then this page will help you get rolling...
Initial Triage
First thing to consider is the quality of the issue (see JRubyBugReportingStyleGuide). If someone is not providing enough info or their reproduction is too large then you can follow up as a comment and ask them for more info. PLEASE NOTE: Every issue report we receive we should treat as a gift. Please treat the reporter in as pleasant of a way as possible. We want them to keep reporting issues and potentially get more involved in our project.
Another important aspect of triaging an issue is which compatibility level is the issue for? Is someone reporting a Ruby 2.2 issue against JRuby 1.7.22 in Ruby 1.9.3 mode? Are they reporting against 2.2 and JRuby 9k, but the compatibility issue has existed since Ruby 1.8.7? Narrow down which Ruby release the bug is valid for and then mark the labels 'JRuby 1.7' and/or 'JRuby 9000'. In a comment specify which versions you tracked the problem back to (e.g. "I can confirm this behavior changed in 1.8.7").
Highly recommended is to use RVM to get each significant release (1.8.7, 1.9.3, 2.0, 2.2.x) and then set up aliases like:
alias mri22='rvm 2.2.2 do ruby'alias mri20='rvm 2.0.0 do ruby'alias mri19='rvm 1.9 do ruby'alias mri18='rvm 1.8.7 do ruby'
Then you can simply run scripts:
mri19 -e '1/ 1.0'
Completing An Issue
Once an issue has been fixed or you determine that the issue is not valid you should mark a milestone in addition to closing the issue.
For issues which are duplicate or invalid you can mark as 'Invalid or Duplicate'. If an issue was deemed not fixable then mark it as 'Wont Fix'. If the issue is not tied to any particular release then mark it as 'Non-Release'.
For issues which have been corrected then there are two rules. First if the issue only affects a single support branch (e.g. only fixes a Ruby 1.8.7 problem on JRuby 1.7.x) then mark it against the current JRuby 1.7 point release (e.g. 1.7.22). If it applies to both release branches then also mark it against the older support branch (e.g. 1.7.22 vs 9.0.1.0). We only do this because github does not support multiple milestone selection at this time. Once we do then we should mark both point releases.
 Add a custom sidebar

Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Triaging
Jump to bottomEditNew page

Thomas E Enebo edited this page Aug 20, 2015
·
2 revisions
For those people interested in helping to triage JRuby issues, then this page will help you get rolling...
Initial Triage
First thing to consider is the quality of the issue (see JRubyBugReportingStyleGuide). If someone is not providing enough info or their reproduction is too large then you can follow up as a comment and ask them for more info. PLEASE NOTE: Every issue report we receive we should treat as a gift. Please treat the reporter in as pleasant of a way as possible. We want them to keep reporting issues and potentially get more involved in our project.
Another important aspect of triaging an issue is which compatibility level is the issue for? Is someone reporting a Ruby 2.2 issue against JRuby 1.7.22 in Ruby 1.9.3 mode? Are they reporting against 2.2 and JRuby 9k, but the compatibility issue has existed since Ruby 1.8.7? Narrow down which Ruby release the bug is valid for and then mark the labels 'JRuby 1.7' and/or 'JRuby 9000'. In a comment specify which versions you tracked the problem back to (e.g. "I can confirm this behavior changed in 1.8.7").
Highly recommended is to use RVM to get each significant release (1.8.7, 1.9.3, 2.0, 2.2.x) and then set up aliases like:
alias mri22='rvm 2.2.2 do ruby'alias mri20='rvm 2.0.0 do ruby'alias mri19='rvm 1.9 do ruby'alias mri18='rvm 1.8.7 do ruby'
Then you can simply run scripts:
mri19 -e '1/ 1.0'
Completing An Issue
Once an issue has been fixed or you determine that the issue is not valid you should mark a milestone in addition to closing the issue.
For issues which are duplicate or invalid you can mark as 'Invalid or Duplicate'. If an issue was deemed not fixable then mark it as 'Wont Fix'. If the issue is not tied to any particular release then mark it as 'Non-Release'.
For issues which have been corrected then there are two rules. First if the issue only affects a single support branch (e.g. only fixes a Ruby 1.8.7 problem on JRuby 1.7.x) then mark it against the current JRuby 1.7 point release (e.g. 1.7.22). If it applies to both release branches then also mark it against the older support branch (e.g. 1.7.22 vs 9.0.1.0). We only do this because github does not support multiple milestone selection at this time. Once we do then we should mark both point releases.
 Add a custom sidebar

Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
Triaging
Jump to bottomEditNew page

Thomas E Enebo edited this page Aug 20, 2015
·
2 revisions
For those people interested in helping to triage JRuby issues, then this page will help you get rolling...
Initial Triage
First thing to consider is the quality of the issue (see JRubyBugReportingStyleGuide). If someone is not providing enough info or their reproduction is too large then you can follow up as a comment and ask them for more info. PLEASE NOTE: Every issue report we receive we should treat as a gift. Please treat the reporter in as pleasant of a way as possible. We want them to keep reporting issues and potentially get more involved in our project.
Another important aspect of triaging an issue is which compatibility level is the issue for? Is someone reporting a Ruby 2.2 issue against JRuby 1.7.22 in Ruby 1.9.3 mode? Are they reporting against 2.2 and JRuby 9k, but the compatibility issue has existed since Ruby 1.8.7? Narrow down which Ruby release the bug is valid for and then mark the labels 'JRuby 1.7' and/or 'JRuby 9000'. In a comment specify which versions you tracked the problem back to (e.g. "I can confirm this behavior changed in 1.8.7").
Highly recommended is to use RVM to get each significant release (1.8.7, 1.9.3, 2.0, 2.2.x) and then set up aliases like:
alias mri22='rvm 2.2.2 do ruby'alias mri20='rvm 2.0.0 do ruby'alias mri19='rvm 1.9 do ruby'alias mri18='rvm 1.8.7 do ruby'
Then you can simply run scripts:
mri19 -e '1/ 1.0'
Completing An Issue
Once an issue has been fixed or you determine that the issue is not valid you should mark a milestone in addition to closing the issue.
For issues which are duplicate or invalid you can mark as 'Invalid or Duplicate'. If an issue was deemed not fixable then mark it as 'Wont Fix'. If the issue is not tied to any particular release then mark it as 'Non-Release'.
For issues which have been corrected then there are two rules. First if the issue only affects a single support branch (e.g. only fixes a Ruby 1.8.7 problem on JRuby 1.7.x) then mark it against the current JRuby 1.7 point release (e.g. 1.7.22). If it applies to both release branches then also mark it against the older support branch (e.g. 1.7.22 vs 9.0.1.0). We only do this because github does not support multiple milestone selection at this time. Once we do then we should mark both point releases.
 Add a custom sidebar

Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Triaging
Jump to bottomEditNew page

Thomas E Enebo edited this page Aug 20, 2015
·
2 revisions
For those people interested in helping to triage JRuby issues, then this page will help you get rolling...
Initial Triage
First thing to consider is the quality of the issue (see JRubyBugReportingStyleGuide). If someone is not providing enough info or their reproduction is too large then you can follow up as a comment and ask them for more info. PLEASE NOTE: Every issue report we receive we should treat as a gift. Please treat the reporter in as pleasant of a way as possible. We want them to keep reporting issues and potentially get more involved in our project.
Another important aspect of triaging an issue is which compatibility level is the issue for? Is someone reporting a Ruby 2.2 issue against JRuby 1.7.22 in Ruby 1.9.3 mode? Are they reporting against 2.2 and JRuby 9k, but the compatibility issue has existed since Ruby 1.8.7? Narrow down which Ruby release the bug is valid for and then mark the labels 'JRuby 1.7' and/or 'JRuby 9000'. In a comment specify which versions you tracked the problem back to (e.g. "I can confirm this behavior changed in 1.8.7").
Highly recommended is to use RVM to get each significant release (1.8.7, 1.9.3, 2.0, 2.2.x) and then set up aliases like:
alias mri22='rvm 2.2.2 do ruby'alias mri20='rvm 2.0.0 do ruby'alias mri19='rvm 1.9 do ruby'alias mri18='rvm 1.8.7 do ruby'
Then you can simply run scripts:
mri19 -e '1/ 1.0'
Completing An Issue
Once an issue has been fixed or you determine that the issue is not valid you should mark a milestone in addition to closing the issue.
For issues which are duplicate or invalid you can mark as 'Invalid or Duplicate'. If an issue was deemed not fixable then mark it as 'Wont Fix'. If the issue is not tied to any particular release then mark it as 'Non-Release'.
For issues which have been corrected then there are two rules. First if the issue only affects a single support branch (e.g. only fixes a Ruby 1.8.7 problem on JRuby 1.7.x) then mark it against the current JRuby 1.7 point release (e.g. 1.7.22). If it applies to both release branches then also mark it against the older support branch (e.g. 1.7.22 vs 9.0.1.0). We only do this because github does not support multiple milestone selection at this time. Once we do then we should mark both point releases.
 Add a custom sidebar

Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Triaging
Jump to bottomEditNew page

Thomas E Enebo edited this page Aug 20, 2015
·
2 revisions
For those people interested in helping to triage JRuby issues, then this page will help you get rolling...
Initial Triage
First thing to consider is the quality of the issue (see JRubyBugReportingStyleGuide). If someone is not providing enough info or their reproduction is too large then you can follow up as a comment and ask them for more info. PLEASE NOTE: Every issue report we receive we should treat as a gift. Please treat the reporter in as pleasant of a way as possible. We want them to keep reporting issues and potentially get more involved in our project.
Another important aspect of triaging an issue is which compatibility level is the issue for? Is someone reporting a Ruby 2.2 issue against JRuby 1.7.22 in Ruby 1.9.3 mode? Are they reporting against 2.2 and JRuby 9k, but the compatibility issue has existed since Ruby 1.8.7? Narrow down which Ruby release the bug is valid for and then mark the labels 'JRuby 1.7' and/or 'JRuby 9000'. In a comment specify which versions you tracked the problem back to (e.g. "I can confirm this behavior changed in 1.8.7").
Highly recommended is to use RVM to get each significant release (1.8.7, 1.9.3, 2.0, 2.2.x) and then set up aliases like:
alias mri22='rvm 2.2.2 do ruby'alias mri20='rvm 2.0.0 do ruby'alias mri19='rvm 1.9 do ruby'alias mri18='rvm 1.8.7 do ruby'
Then you can simply run scripts:
mri19 -e '1/ 1.0'
Completing An Issue
Once an issue has been fixed or you determine that the issue is not valid you should mark a milestone in addition to closing the issue.
For issues which are duplicate or invalid you can mark as 'Invalid or Duplicate'. If an issue was deemed not fixable then mark it as 'Wont Fix'. If the issue is not tied to any particular release then mark it as 'Non-Release'.
For issues which have been corrected then there are two rules. First if the issue only affects a single support branch (e.g. only fixes a Ruby 1.8.7 problem on JRuby 1.7.x) then mark it against the current JRuby 1.7 point release (e.g. 1.7.22). If it applies to both release branches then also mark it against the older support branch (e.g. 1.7.22 vs 9.0.1.0). We only do this because github does not support multiple milestone selection at this time. Once we do then we should mark both point releases.
 Add a custom sidebar

Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
Triaging
Jump to bottomEditNew page

Thomas E Enebo edited this page Aug 20, 2015
·
2 revisions
For those people interested in helping to triage JRuby issues, then this page will help you get rolling...
Initial Triage
First thing to consider is the quality of the issue (see JRubyBugReportingStyleGuide). If someone is not providing enough info or their reproduction is too large then you can follow up as a comment and ask them for more info. PLEASE NOTE: Every issue report we receive we should treat as a gift. Please treat the reporter in as pleasant of a way as possible. We want them to keep reporting issues and potentially get more involved in our project.
Another important aspect of triaging an issue is which compatibility level is the issue for? Is someone reporting a Ruby 2.2 issue against JRuby 1.7.22 in Ruby 1.9.3 mode? Are they reporting against 2.2 and JRuby 9k, but the compatibility issue has existed since Ruby 1.8.7? Narrow down which Ruby release the bug is valid for and then mark the labels 'JRuby 1.7' and/or 'JRuby 9000'. In a comment specify which versions you tracked the problem back to (e.g. "I can confirm this behavior changed in 1.8.7").
Highly recommended is to use RVM to get each significant release (1.8.7, 1.9.3, 2.0, 2.2.x) and then set up aliases like:
alias mri22='rvm 2.2.2 do ruby'alias mri20='rvm 2.0.0 do ruby'alias mri19='rvm 1.9 do ruby'alias mri18='rvm 1.8.7 do ruby'
Then you can simply run scripts:
mri19 -e '1/ 1.0'
Completing An Issue
Once an issue has been fixed or you determine that the issue is not valid you should mark a milestone in addition to closing the issue.
For issues which are duplicate or invalid you can mark as 'Invalid or Duplicate'. If an issue was deemed not fixable then mark it as 'Wont Fix'. If the issue is not tied to any particular release then mark it as 'Non-Release'.
For issues which have been corrected then there are two rules. First if the issue only affects a single support branch (e.g. only fixes a Ruby 1.8.7 problem on JRuby 1.7.x) then mark it against the current JRuby 1.7 point release (e.g. 1.7.22). If it applies to both release branches then also mark it against the older support branch (e.g. 1.7.22 vs 9.0.1.0). We only do this because github does not support multiple milestone selection at this time. Once we do then we should mark both point releases.
 Add a custom sidebar

Clone this wiki locally