search

oslc-op / website

Hugo sources for the OSLC website
https://open-services.net
6 stars 8 forks source link

WG Infrastructure Proposal #146

Closed brianking closed 5 years ago

brianking commented 7 years ago

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 commented 7 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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:

Anything else?

rersch commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 #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 commented 5 years ago

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