For questions about this archive, please contact webmaster@hl7.org.
Wayne Kubick (Feb 13 2018 at 15:35):A set of guidelines on how to use templates, such as decision logs, will be prepared and made available for new workgroups prior to the Cologne WGM.
David Johnson (May 16 2018 at 12:56):Does anyone have any suggestions on best practices for doing meeting minutes?
David Johnson (May 16 2018 at 12:58):This is specific to Confluence
David Johnson (May 16 2018 at 12:59):I've seen some good examples, but I want to make sure before I start answering people's questions.
David Johnson (May 16 2018 at 12:59):I understand that minutes can be hard to manage in the confluence page tree as they accumulate
David Johnson (May 16 2018 at 13:00):I like the table-based stuff that OO is doing here: http://confluence.hl7.org/display/OO/OO+Meeting+Minutes
David Johnson (May 16 2018 at 13:00):But still need to figure out that page tree
Dave Hamill (May 16 2018 at 13:00):As for the fields that should be in a Minutes template, we do have a Minutes template in MS Word at HL7.org > Resources > Templates
David Johnson (May 16 2018 at 13:01):Thanks Dave! I think the actual minutes are looking good for people, and the templates are great to have, but it's that page tree and management of the bulk that comes over time that gets teejus.
David Johnson (May 16 2018 at 13:01):Teejus. Wow.
David Johnson (May 16 2018 at 13:01):/me is midwestern.
Joginder Madra (May 24 2018 at 20:38):One thing you can do is create an archive within the page tree. This is what the PH Work Group has done with our meeting notes.
David Johnson (May 25 2018 at 13:33):I see it there. I like it!
David Johnson (Sep 10 2018 at 17:26):Let's use this to discuss account creation
Joshua Procious (Sep 10 2018 at 17:36):I can either stop open account creation, or create a new group which new users are assigned by default which only has view permissions, then as users need access they may submit to be added to jira-core-users. the second option has less overhead per new user.
David Johnson (Sep 10 2018 at 17:37):I like the second option. That means all new accounts are handled quickly, and the gatekeeping is to jira-core-users
Joshua Procious (Sep 10 2018 at 17:39):applying that now.
Lloyd McKenzie (Sep 10 2018 at 17:49):The only reason for users to request an account is because they want write access - everyone gets read access if they're a member of the public
Lloyd McKenzie (Sep 10 2018 at 17:50):So everyone asking for an account needs to be immediately put in the review queue for a proper account
David Johnson (Sep 10 2018 at 17:50):okay, that works under what Josh is doing now
Lloyd McKenzie (Sep 10 2018 at 17:51):The question is: how do you get enough information to allow you to evaluate someone's request
David Johnson (Sep 10 2018 at 17:51):He is making a base-user account that new users will be immediately assigned to.
Lloyd McKenzie (Sep 10 2018 at 17:51):Would it work better to have a "public" Jira tracker people can request ids from that we can then evaluate (preferably automatically) to grant access?
David Johnson (Sep 10 2018 at 17:53):It seems th
Lloyd McKenzie (Sep 10 2018 at 17:53):Right but the base user account will be useless
David Johnson (Sep 10 2018 at 17:53):ere are two issues we are dealing with, and one is confluence based and one is jira based
David Johnson (Sep 10 2018 at 17:53):okay,
David Johnson (Sep 10 2018 at 17:53):I don't know the business rules well enough to determine h
David Johnson (Sep 10 2018 at 17:54):ow this should be setup for both systems. But we must turn off jira-core-user edit access in confluence
David Johnson (Sep 10 2018 at 17:54):if we want to keep the jira-core-user as the base account, that's okay, as long as they cannot create any content in confluence
Lloyd McKenzie (Sep 10 2018 at 17:54):The general public has full read access to everything relevant without a logon. (Or at least they should - if not, we need to fix that.) So the only reason to request a logon is because you want to create and update stuff.
Lloyd McKenzie (Sep 10 2018 at 17:55):We don't want spammers to have the right to create or update stuff on Jira or Confluence
Joshua Procious (Sep 10 2018 at 17:55):the general public does have full read access
Lloyd McKenzie (Sep 10 2018 at 17:55):So the question is: What is our process for keeping spammers out?
David Johnson (Sep 10 2018 at 17:55):hold on
David Johnson (Sep 10 2018 at 17:55):because spammers have the right to create and update stuff in confluence with the jira-core-users account in confluence
Lloyd McKenzie (Sep 10 2018 at 17:56):jira-core-users have the right to create spam tracker items and comments in Jira too
David Johnson (Sep 10 2018 at 17:56):so what you're saying about 'we need to fix that' is immediately valid in confluence
David Johnson (Sep 10 2018 at 17:56):do you want them to?
David Johnson (Sep 10 2018 at 17:56):because i don't :-)
Lloyd McKenzie (Sep 10 2018 at 17:57):The ideal solution is: User self registers and gets basic write access to Jira and Confluence after an automated evaluation determines that they're legit and, on occasion, passes 'questionnable' registrations on for human review.
Lloyd McKenzie (Sep 10 2018 at 17:58):The issue with emailing the webmaster is that it creates a delay and creates extra workload for the two of you.
David Johnson (Sep 10 2018 at 17:58):Lloyd, that sounds like anonymous write access to me.
Lloyd McKenzie (Sep 10 2018 at 17:59):We could give anonymous write access to a single project that doesn't allow anonymous read
Lloyd McKenzie (Sep 10 2018 at 17:59):That project could be used for registration submissions
Lloyd McKenzie (Sep 10 2018 at 17:59):It could enforce username and proper name policies
David Johnson (Sep 10 2018 at 17:59):what group would that belong to?
Lloyd McKenzie (Sep 10 2018 at 17:59):public
Lloyd McKenzie (Sep 10 2018 at 17:59):(for write)
David Johnson (Sep 10 2018 at 18:00):so, a new group called public, that all new accounts are assigned to, that can create a tracker, and has basic view access in confluence?
Lloyd McKenzie (Sep 10 2018 at 18:00):no
Lloyd McKenzie (Sep 10 2018 at 18:00):No group
David Johnson (Sep 10 2018 at 18:00):each
Lloyd McKenzie (Sep 10 2018 at 18:00):"public" is something you can grant permsisions to directly
David Johnson (Sep 10 2018 at 18:00):account has to be assigned agroup on account creation
Lloyd McKenzie (Sep 10 2018 at 18:01):Public already has basic view access in confluence and Jira
David Johnson (Sep 10 2018 at 18:01):let's not talk about Public as though it's a group then, that is anonymous, right?
Lloyd McKenzie (Sep 10 2018 at 18:01):They'd submit to the tracker. The tracker's automated process would then create an account under jira-core-user.
David Johnson (Sep 10 2018 at 18:01):the question is what group are new accounts associated with, because there HAS to be one.
Lloyd McKenzie (Sep 10 2018 at 18:02):I don't remember the name of the permission label. It could be anonymous. I thought it was public.
David Johnson (Sep 10 2018 at 18:02):the permission label is most likely anonymous.
David Johnson (Sep 10 2018 at 18:02):the real meat here for me is not what is displayed when you don't have an account, it is what group are new accounts assigned to.
Lloyd McKenzie (Sep 10 2018 at 18:03):ok. (startiung to chair a call, back in a bit)
David Johnson (Sep 10 2018 at 18:03):cool, we'll keep this open
Lloyd McKenzie (Sep 10 2018 at 18:03):If the standard Confluence account creation mechanism isn't enough, then we replace it with our own. Once a user is "successful" they should end up in jira-core with basic write access to everything.
Joginder Madra (Sep 10 2018 at 18:04):My suggesting is to handle write access to Jira and Confluence separately. Just because someone is able to create tracker items should not mean that they are automatically able to create/edit pages in Confluence.
David Johnson (Sep 10 2018 at 18:04):well, let's make sure we don't call it the confluence account creation. It is the Atlassian account creation and immediately applies to both systems.
David Johnson (Sep 10 2018 at 18:07):Does that make sense? Account creation for both Confluence and Jira are done when the user signs up for Jira.
Joginder Madra (Sep 10 2018 at 18:18):From my perspective, it makes sense to grant access to Jira and Confluence at the same time (if user counts are not an issue). However, I do feel that base-level Confluence access should not include the ability to create spaces or update existing spaces/pages...that should come afterwards unless you are capturing that information at account creation along with the appropriate signoff from the Space owner/administrator
Lloyd McKenzie (Sep 10 2018 at 19:43):We want all Confluence users to be able to do things like mark their attendance at meetings - which means update page privileges.
David Johnson (Sep 10 2018 at 20:04):This is a high-level discussion so I feel it is safe to say that that is not the best use of Confluence.
David Johnson (Sep 10 2018 at 20:10):Must away, I'll read up responses later.
Lloyd McKenzie (Sep 10 2018 at 20:13):I'm fine with not capturing attendees in Confluence. I expect FHIR-I will continue to use a Google Doc - at least until there's a version of Confluence that won't have collision issues. And if that were the case, then we could restrict editing Confluence pages to "HL7 Trusted Users" - the same people who can triage trackers
Joginder Madra (Sep 10 2018 at 20:25):This is not how all work groups work with Confluence, so we should not assume that this is the approach that all would want. For example, the Public Health work group has the scribe of the session (who already has write access) take attendance
Lloyd McKenzie (Sep 10 2018 at 21:10):I was just reflecting the decision from the Jira/Confluence calls that we wanted everyone to have write access to Confluence.
Lorraine Constable (Sep 10 2018 at 22:00):On the wiki we use captcha sparingly when we want to ensure it is at least a real person - would that work in the user self registration page?
Lloyd McKenzie (Sep 10 2018 at 22:00):In terms of preventing spammers, if we can check emails against the listserves, chat.fhir.org, hl7.fhir.org and the membership database, anyone who's on one of them can presumably be approved.
Lorraine Constable (Sep 10 2018 at 22:02):anonymous is the label for allowing public read access (or whatever public access you wish). I just turned anonymous read on in the Jiracon space yesterday, as it wasn't already
Lloyd McKenzie (Sep 10 2018 at 22:02):How effective is captcha in keeping out spammers? The alternative is for the submission form to ask for an email of someone who vouches for them (said email needing to be in one of those lists) and we can then auto-fire off an email to the "sponsor" and approve the request when we get a response back.
Lorraine Constable (Sep 10 2018 at 22:05):when we brought it in, captcha definitely slowed the crap we were getting on the wiki, particularly around external links (which is why that is the only place we are still using it). Does not guarantee you are not a spammer, but does confirm you are a person rather than a bot
Lorraine Constable (Sep 10 2018 at 22:06):This topic should go on EST's agenda for this week as well
Lorraine Constable (Sep 10 2018 at 22:11):@Joginder Madra - granting logon access at the same time does not necessarily mean the permissions need to be configured the same for both. One of our guiding principles had been that we want at a minimum the access we have on the current wiki - any logged in user can create a page in the wiki. And, for both attendance logging and for discussion items, many groups have open entry on the page. Does not mean everyone has to
Lorraine Constable (Sep 10 2018 at 22:16):Using the "what do we do on the wiki" test - we turned off the ability to create an account on your own there, and an administrator needs to create. It seems that response has been fairly quick. What is the realistic overhead? I suspect the bulk of the account creation will be when we first do a Jira ballot, but hopefully many stakeholders are already on line by then.
Or do we proactively create a log in for all members who have the right to submit ballot comments?
Lloyd McKenzie (Sep 10 2018 at 22:27):The main reason for super-fast approval is if we want people to self-register in meeting minutes. Other use-cases, waiting for a few hours (or even a few days) isn't the end of the world. When we import people from the ballot signup process, we'll generate users for the new email addresses.
Joshua Procious (Sep 11 2018 at 13:02):i second that notion
Last updated: Mar 23 2020 at 00:02 UTC