Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WG Infrastructure Proposal #146

Closed
brianking opened this issue Sep 20, 2017 · 10 comments
Closed

WG Infrastructure Proposal #146

brianking opened this issue Sep 20, 2017 · 10 comments

Comments

@brianking
Copy link
Contributor

brianking commented Sep 20, 2017

Currently Working Groups are:

  1. A site landing page
    e.g. http://open-services.net/workgroups/alm-plm-interoperability-2nd-edition/
  2. A mailing list
    e.g. http://open-services.net/mailman/listinfo/oslc-plm_open-services.net
  3. A forum
    e.g. http://open-services.net/forums/viewforum/23/
  4. Wiki pages
    e.g. http://open-services.net/wiki/alm-plm-interoperability-2nd-edition/

We can still provide a landing page. I propose we keep the current url and as now, each WG would be a sub-page. We could provide a markdown template suitable for our Hugo installation that can just be cloned and deployed easily for new groups.

We will be retiring mailing lists and the current forum (archiving as read-only, and removing as necessary). However, both of these can be replaced with our new Discourse instance, which has both list-type and forum functionality built-in.

The big open question is about the wiki. My original plan was to setup and instance of MediaWiki. However, what this means is extra cost both in terms of $$$ (mainly hosting) and maintenance time (all wikis are spam magnets, and require user approval/monitoring). So the question is, can or should we provide some other way for WGs to document their activities? There are a few options:

  1. Use Discourse as well for documenting. It might not be ideal for all use cases, for example when multiple revisions are needed.
  2. Use Github. Each WG gets a project under https://github.com/OSLC/ which will give them a repository, a wiki, ability to create projects, ...
  3. Let WGs decide themselves what 3rd party tools they use, e.g. Google Docs, Dropbox Paper, ...

I think we should move away from the idea that we need to provide all the infrastructure for the community, mainly because of the maintenance overhead. Most times, there is probably a better solution (free or not) out there anyway.

For this reason I propose for documentation we go for either Github or letting the WGs decide what they want to use.

- Brian

cc @rersch @wesleycoelho

@rersch
Copy link
Contributor

rersch commented Sep 21, 2017

I like the idea to use Github projects for the UGs, if this keeps the admin overhead low. It's better than letting the projects decide and all are using different tools. Since I cannot judge all implications at the moment, can we ran a little experiment with the planned Pattern UG? Can you create a Github project, and a (minimal) landing page pointing to the Github project?
Wesley and I could try to populate this with our first ideas. For the Pattern UG we want to build a pattern library. I sure, this can be realized with Github in an easy way.
Will it be possible for the UG to update the landing page frequently? e.g. announcing the next meeting, publishing news, etc.
Rainer
cc: @brianking @wesleycoelho

@brianking brianking moved this from To Do to In Progress in Site Design and Development Sep 22, 2017
@brianking
Copy link
Contributor Author

Rainer,

I've setup the project at:
https://github.com/OSLC/lifecycle-integration-patterns

I added you as admin, so you can do pretty much anything including adding new users (Settings -> Collaborators&Teams).

For the landing page, you can probably just use the README. Alternatively you could create a wiki page, and just point to it from the README.

Let me know if you have any questions.

@wesleycoelho
Copy link

Hi @brianking, I like your suggestion of using the GitHub wiki for the WG documentation. I just tried it out and it looks like a good solution for documenting the patterns. We could link there from the README as you suggested.

CC: @rersch

@brianking
Copy link
Contributor Author

Landing page is up on the test site:

https://oslc.github.io/workgroups/lifecycle-integration-patterns/

Feel free to make a pull request to update the content, or send to me and I can update.

https://github.com/OSLC/oslc-site-hugo/blob/master/content/workgroups/lifecycle-integration-patterns.md

@rersch
Copy link
Contributor

rersch commented Sep 26, 2017

I made a small change to the page and committed the change.
What's now needed to publish this change. Should I be able to do this?

@brianking
Copy link
Contributor Author

I went ahead and pushed your change, it is live. Only I and the developers can push changes to the live site right now. FYI over the coming days we will likely be transitioning away from oslc.github.io as the live site, and instead using oslc.co. We try to deploy at least once a (work week) day.

I think we should make a template for a WG landing page. What information needs to be on there? To start with, I would add:

  • Wiki (link to github wiki intro page)
  • Forum (link to Discourse category)
  • Workgroup leads (names of leads that link to their profile on a network such as LinkedIn or Twitter, or their personal page)

Anything else?

@rersch
Copy link
Contributor

rersch commented Sep 28, 2017

I assume you also plan a short description of the workgroup on the landing page (template) – right?

On the “old” (open-services.net) Workgroups we also had a link to the meeting schedules.
The schedule page itself was on the wiki. Maybe we should have a template for this as well.

How about a link to (open) issues of the workgroup? Or how to submit issues for the WG?

Where will the landing page be placed? Will it be the README.md of the Github project or
will it be an entry page of the Wiki? In any case the Workgroup itself should be able to
update the landing page (changes of WG lead and status, additional links, if needed, etc.)

We also should have a set of (setup) instructions for new workgroups. These could either be
integrated in the template (to be removed when the WG goes life), a separate document or
an initial set of issues. Actually, I like the first best, because it forces the WG to do something
with it.

@jamsden
Copy link
Member

jamsden commented Nov 28, 2017

We need a link from the home page to the workgroups, I couldn't find one.

The icons on the http://oslc.co/workgroups/ page are ok, but the text descriptions are partially occluded and can't be scrolled - there's no way to read the text. Hover over a workgroup further occludes the text and pops up the See more button. I would rather the text was scrollable and clicking on the workgroup name brought you to the workgroup home page. Hover buttons like that are a jarring UI.

Need a link or paragraph on the bottom of the page to give instructions on creating a new workgroup.

As far as the infrastructure is concerned, the instructions for workgroup creation could assume GitHub. If a workgroup wanted to use something else, they could and provide links in their home page.

@gabrielfdac
Copy link
Collaborator

@jamsden the link to workgroups is in the Contribute page.

Some things to note about the homepage is that

  1. It is undergoing a complete overhaul both in layout and content, so the current version is not a good representation of what's going to be in the end. (See issue New Homepage Design/Content #198 for more details)
  2. As part of the layout change what we're trying to achieve is a proper introduction for new comers. That means being simple and specially not overwhelming them with too much information, or too technical information. I understand the importance of the workgroups from the perspective of the community. However I would argue new comers are not ready for it yet. So I believe we should incentivize them in the homepage to visit our Contribute page instead. And from there they could choose what they want to contribute on including our workgroups.

On the boxes I agree that the overall styling of the paragraphs are not good. And the hover had a different intent in concept than what's currently implemented. I'll revisit it some time soon.

On Instructions Good suggestion. Perhaps adding a wiki page in this repository for it would be the best approach? And then we could link to it at the bottom of the page.

@berezovskyi
Copy link
Member

Closing this as we all use GH in the OP and no WGs are needed any more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

6 participants