Hi all,
@SevKohler has rightly suggested that we add a page to the website for all our working groups, including the collabs with FHIR & OMOP. This is a good idea and one I will take forward, but before I wade into it, I’d like an idea of what we need to include (Members? History? Updates…?), how many groups (and subgroups?) there are, whether we want to direct people here for scheduling meetings, progress reports etc… (@marcusbaw)
Drop me a line if you’re involved and would like your working group on the webpage, and we’ll get the ball rolling.
Pete
Hi Pete
In CPB we have a Confluence heading for our related WGs.
Paul
4 Likes
Thanks @Pete_Bouvier - we can create private or open companion discussion spaces here in Discourse for any WGs which would like a space.
I’m equally happy for groups to use Confluence if they prefer that style of knowledgebase.
Having a complete list of the WGs somewhere does seem like a good idea, and the website might as well be that place. Then just link to whatever each WG sees as their main place of discussion/point of presence.
1 Like
I would propose the thing HL7 did, so people can see and also know who is in charge if anybody wants to join.
The WG lead can then decide what to do.
Also its especially good for transparency within the community which i find most important.
https://confluence.hl7.org/spaces/HL7/pages/4489802/HL7+Work+Groups+Projects
2 Likes
Information about working groups should be something dynamic and flexible, easy to update and maintain, so Confluence is a better option to put all the details. In the website, which is more static, I would only include a link to that Confluence.
6 Likes
It seems a little silly to run both Confluence AND Discourse for this sort of collaboration at scale, unless you are into siloing, fragmented systems, duplicated user data, and poor interoperability! Oh, and increased cost.
Of note, SNOMED have just moved from Confluence/Jira to Discourse for exactly this type of functionality:
Nice looking site, too.
1 Like
Thanks @Nathan - I didn’t know SNOMED had moved to Discourse. Nice site, although not that much traffic on it compared to the size of SNOMED’s global reach (or at least I thought from a quick look).
I haven’t got involved with any of the Confluence/Jira Atlassian tools - some people do seem to like them and I don’t see any advantage in forcing people off the platforms they like and are productive on. Transferring a large knowledgebase over to Discourse would be a lot of re-work for people. So unless Confluence/Jira got very expensive or started doing messed-up things with the IP or T&C, we can allow both to work in parallel. They are both URL-linkable and so jumping from one to the other is fairly streamlined.
My general approach is to recommend that new knowledgebase is developed in Discourse, but I accept that for some groups they just like Jira/Confluence better, and that’s fine with me.
I think we all hate jira/confluence. But it’s bee there for decades. And has some nice features like tying issues, knowledge gathering, change requests and releases together. Most of that has been made redundant by GitHub. And we see some features slowly move to GitHub.
Similar to how most of slack has been made redundant by discourse. But chat is still poor on discourse (notifications are non functional for me). So for coordinating work I still use slack’s adl2 channel.
sec is migrating the technical infrastructure for the specs. So it’s a good time to discuss our development pipeline from questions/issues to published specs.
And there diffinitly opportunities for improvement. But I’d be reluctant to do a big migration right now. For the reasons you specify as well as historical stability around changes and documentation. But we could experiment a bit.
So if we would do wiki style discussions on discourse how would we tie that in to the rest of the atlassianverse?
1 Like
Wikis are a feature of Discourse but I’d be the first to admit, even as a Discourse fan, that Discourse’s Wiki functionality is not fully mature. There are no ‘talk’ pages, and although there is granular edit history with full reversion, there is no way to ‘pull request’ a patch or improvement, and access controls as to who can edit what are not straightforward.
For example: you can ‘Wikify’ a topic, which then means that anyone in a group specified in the ‘Edit wiki post allowed groups’ site setting (currently @admins @moderators @trust_level_2 ) can now edit that Wiki. Additional controls can be added by placing the wiki somewhere that ordinary users can’t see it, but at this point it starts to defeat the object of open documentation.
I would not push you to leave Jira/Confluence. I share your hatred of it, but I understand when something is in place and working, why mess with it?
I think using code-forge tools (GitHub, GitLab, and similar) is to be supported and it has advantages where ther object of discussion is reflected in a codebase, and so you can link Issues to Pull Requests to Commits, and have an ‘audit trail’ on code changes. GitHub is dominant but many others are available, many have become more popular since the Microsoft buyouf of GitHub.
Some tools I’ll share just to enrich the debate:
Discourse has a GitHub plugin which adds a small number of features which can be useful for teams using GitHub and Discourse a lot:
If I wanted a good Wiki I would tend towards something like this:
2 Likes
Hi all.
By my reckoning, we have 4 separate HL7 working groups, one for CPB, a new one in the pipeline for OMOP…. any more for any more?
As for the relative benefits of Discourse and Confluence… that’s another story 
P
Hey the SEC has several:
Mapping WG
REST API WG
Template ID version WG
Federation WG lead by EY
There are also others like the GDL WG ?
@sebastian.iancu @rong.chen
We need to send you the info about the leads description and when the WG occurs.
2 Likes
RDA has mature examples, see Group Directory
Perhaps a bit overkill to start with … but use it as a dot on the horizon 
3 Likes