contributor guidelines, CLAs and attribution

Tony Atkins tony at raisingthefloor.org
Fri Oct 6 14:09:38 UTC 2017


Hi, Justin:

I forgot about this earlier, but another option is to put HTML and
javascript in the site banner.  The banner appears at the top of the page
by default, but I've seen cases in which javascript was used to create
content in other areas.   That's much less involved than customising
templates, but does require some testing and finesse to ensure that the
selectors etc. you use in your script haven't changed in an updated version
of JIRA.

Cheers,


Tony

On 6 October 2017 at 13:34, Justin Obara <obara.justin at gmail.com> wrote:

> Hi Tony,
>
> Thanks for looking into this. While I’d prefer to have something on every
> page and on signup, it sounds like Option 3 is the most likely to work and
> keep working consistently. In an ideal world we’d have something in all
> three places, but I’d vote for starting with Option 3 and going from there
> as needed.
>
> Thanks
> Justin
>
>
> On October 6, 2017 at 5:21:59 AM, Tony Atkins (tony at raisingthefloor.org)
> wrote:
>
> Hi, All:
>
> There was a tangential question about whether we could cover this by
> customising the signup page or site footers on our JIRA instance.  I took a
> few minutes to look at the options.  In short, we can:
>
>    1. Modify one of the built-in templates.
>    2. Install a plugin that adds the ability to customise the JIRA UI.
>    3. Add the "introduction gadget" to the default system dashboard.
>
> The first two options represent additional work for each and every
> upgrade.  Modifying the template assumes that we would deploy our modified
> templates on each upgrade, and that we would test the changes before
> upgrading.  If we decide that editing templates is the way to go, I would
> recommend updating the footer template
> <https://confluence.atlassian.com/jira061/jira-administrators-faq/usage-faq/modifying-the-jira-footer>,
> which is written in velocity, and has fewer key variables and includes to
> screw up when modifying it.  The signup page template is written in Soy,
> which is very code-like and lends itself more easily to breakage.  The
> signup template is also much more opaque with regards to what you'd need to
> change and how, probably reading Java classes and language files would be
> involved.
>
> The plugin route is somewhat simpler, but requires us to trust a vendor to
> maintain their plugin well, and to deliver compatible versions of their
> plugin frequently enough that it doesn't prevent us from being able to
> upgrade when we choose to.  I asked my friends who work on a similar
> theming plugin for Confluence, they didn't have an opinion on the JIRA
> side, so someone (I assume me) would need to take a bit to review the range
> of plugins and recommend one.
>
> The third option, which I would recommend, is to add the "introduction
> gadget
> <https://confluence.atlassian.com/jira064/adding-the-introduction-gadget-720416983.html>"
> to the default system dashboard.  The text that appears there is
> customisable, and this is a built-in feature.  We use that already on the GPII
> JIRA instance <https://issues.gpii.net/>.  Although it does take up some
> screen real estate, anyone who logs in can customise their dashboard, i.e.
> only new users and people who haven't signed in would absolutely have to
> see it.  This doesn't give us quite the fine-grained control of the other
> two options, but is much much easier to maintain, and would take about five
> minutes to implement once we agree on the wording.
>
> Cheers,
>
>
> Tony
>
>
>
> On 2 October 2017 at 13:42, Justin Obara <obara.justin at gmail.com> wrote:
>
>> Hi Colin,
>>
>> Sounds good, thanks.
>>
>> For reference, here’s the link to the channel discussion
>> https://botbot.me/freenode/fluid-work/2017-09-28/?msg=91673628&page=1
>>
>> Thanks
>> Justin
>>
>> On September 28, 2017 at 3:59:17 PM, Clark, Colin (cclark at ocadu.ca)
>> wrote:
>>
>> Hi Justin,
>>
>> Just a summary from our discussion in the channel: I think it makes sense
>> to decouple the issue of changing our approach to CLAs from the more
>> general issue of publishing our contributor guidelines. Why not publish
>> guidelines now, reflective of our current process, and then we can change
>> them when we're clear on how we want to handle CLAs in the future?
>>
>> Thanks,
>>
>> Colin
>>
>> ---
>> Colin Clark
>> Lead Software Architect,
>> Inclusive Design Research Centre, OCAD University
>> http://inclusivedesign.ca
>>
>> On Sep 28, 2017, at 9:51 AM, Justin Obara <obara.justin at gmail.com> wrote:
>>
>>
>> Hi Colin and Simon,
>>
>> After reading over the hacktoberfest event, it got me thinking about our
>> need to add the contributor guidelines to the repo. We have a JIRA for this
>> (FLUID-5959 <https://issues.fluidproject.org/browse/FLUID-5959>).
>> However, I’ve been holding off on adding this till we updated our process
>> for CLAs and contributor attribution (see: FLUID-6106
>> <https://issues.fluidproject.org/browse/FLUID-6106>). I wonder if there
>> has been any progress on that front and, if not, if there is something I
>> and/or others in the community could do to assist with it? Also, if you
>> feel that the process for updating our use of CLAs and contributor
>> attribution will take a while, I could look at adding the contributor guide
>> to the repo first and we can update it later.
>>
>> Thanks
>> Justin
>>
>>
>>
>> _______________________________________________________
>> fluid-work mailing list - fluid-work at lists.idrc.ocad.ca
>> To unsubscribe, change settings or access archives,
>> see https://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20171006/ffe2ea6f/attachment.html>


More information about the fluid-work mailing list