To keep all community content under community control.
Content
The ansible/community repo contains:
Community Day/Contributor summit slides
Working group meeting details
some content that might be outdated (TBD but hasn’t been touched in 2+ years).
Impact
If we transfer the entire repo to a new repo in the ansible-community org, there should be no impact. It will include the existing license and all issues/PRs and GitHub will redirect links to the new repository.
Thanks @samccann. The one area that seems risky to me is the posts in https://github.com/ansible/community/tree/main/posts - those have a GitHub Pages site that renders them as blog posts, and they’ve been linked around the web a lot. Breaking those links would be painful.
Looking at the docs you linked:
If the transferred repository contains a GitHub Pages site, then links to the Git repository on the Web and through Git activity are redirected. However, we don’t redirect GitHub Pages associated with the repository.
So we can’t handle that in some “nice” way because we can’t control redirects on GitHub (see, this is why I want us to own our platform, it applies to Google Groups too), so if we decide to move it, we’ll need a plan to try and deal with this - and that probably applies to the slides too. I think the only options are (a) suck it up, or (b) leave a skeleton repo behind to handle redirects in a simple Pages site.
The working group stuff should move here, tbh, and that’s already in progress, and outdated stuff can clearly be deleted/archived
We should also leave a placeholder as well, that could help with the pages redirect
Are we using a custom domain for the Github Pages in the repo? Or are we relying on the default project.github.io namespace? If we used a custom domain, we could do something with the DNS or a proxy.
If we are using the default github.io offering then we could keep some kind of placeholder repo for the Github Pages and redirect them there, but not sure if creating a placeholder repo with the same name will allow us to keep all the other redirectes of the move repo feature.
Okay so transferring the whole repo will break the GithHub pages. So how about we fork it and archive the old one ? This gives us an exact copy which we can then go in and clean up. AFAIK the github pages will still work from the old one and we won’t set it up on the new one. We now have this forum (and soon a website blog) - we won’t need to use it for blogs anymore. That leaves us with things like new slide decks. But we can take a bit of time to think about where those should be published. I feel the github pages were too ‘hidden’ for people to be aware they could find stuff there.
But we should wait for @cybette to chime in as she may know more about the visibility of slides/presentations.
We would also have to communicate with all the Working group teams to have them move to the new repo before we can archive the old. That would be an opportunity to convince them the forum is a better place
Lastly, we’d need to go through the 99 open issues and decide if any of them should be transferred (besides the obvious active working group ones).
For the few blog posts, let’s move them and add meta redirects in the original html, then archive the repo. As well as a redirects at the root of the old GitHub page.
This is a wiki post, so anyone can update with steps we need to take.
Steps to fork and archive ansible/community
Open issue in ansible/community to capture attention of repo watchers. Point to this plan.
Wait a week or so, then create the new repositories:
ansible-community/presentations - to hold slide decks for community events (not meetups)
ansible-community/meetings - to hold the irc logic and .yaml files that create the sharable ansible calendar for working groups
Review all open issues in the ansible/community and close out those we won’t implement
Communicate to all Working Groups using the meeting agenda issues -propose how to use the Forum instead.
Transfer all remaining open issues to the new repo. set up GitHub Pages in new repo
Blogs will remain archived in ansible/community so no impact on existing links to them or the Pages they are at. Redirect old GitHub Pages to new pages for priority content (blog posts, slides?)
Update ansible/community README to describe where the content has moved to
oh nvm I see it’s already up on the draft website. So post-fork, should we remove them from the new repo and/or replace them with a link to the website?
+1 to fork and archive, and not have github pages on the new one. Many of the old blog posts and slides were linked from past Bullhorn issues, wiki pages, possibly reddit and other social channels.
For blog posts, I think we should remove them from the new repo post-fork since we will have a blog in the new website and let’s not have multiple places show up when people search for Ansible blogs.
As to where to store new slide decks we can discuss where is the most suitable place for them, as before this we didn’t have either the forum or the website!
Mostly I added two of them to illustrate importing and hosting our own content and how to do it. The real concern is that links to the originals exist in other people’s content around the web, and I wouldn’t want to break them, so they need to stay.
@cybette has it right, we can just not move the pages stuff over, and freeze it at that point, with a suitable explanation in the old repo.
Okay thanks. I updated the checklist a bit to reflect removing blogs/slides from the new repo and not using GitHub pages on the new repo. I’ll start communicating this soon to the WGs and a general issue on the ansible/community repo to hopefully capture the attention of the watchers.
I updated the checklist again. Since we don’t want to repeat the generic ‘dumping ground’ that was ansible/ community, I’m proposing the following:
Create ansible-community/presentations - copy over the existing decks and use this as a location for all sharable presentations from community events (such as summits, community days etc). NOTE - meetups already have dedicated repos to share their slides.
Create ansible-community/meetings - this is to hold the files etc that create the shared ansible working group ics calendar.
I don’t think we can create something like that shared/downloadable ics calendar from the community events calendars here, can we @gwmngilfen ?
There are also some working group subdirectories that have what could be old/stale content:
/group-networking
/group-aws
/groups-security
I’ll reach out to those three groups to verify, but it does bring up the need for dedicated documentation that some working groups need - Home · ansible/community Wiki · GitHub
I’d like to understand how we could use the forum to replace that wiki/dedicated .md files per working group here. I know we have the ability to create pages here, but is that the best approach?
I couldn’t find specific documentation that GitHub pages remain after a repo was archived, so I did a little test… and it seems they do stay up -My GitHub experiments | experiments
(the repo under that is archived).
As part of this repo move, we have the opportunity to create a new repo specifically for slide decks from presentations. Before we do this, is there some other/better way going forward that we want to host these presentations? We had this older issue talking about it but not much progress.
Sadly not - I’ve asked for it from CDCK, but today that’s not possible. You can get an ICS file from a single event, but not a whole calendar.
So we also have stuff on docs.ansible.com relating to the Working Groups - at a minimum that’s a duplication, so removing it here seems wise - but the unique content still needs a home.
To that end, I always saw us having dedicated docs that change infrequently (processes, rules, etc) on a site of some kind, rather than here. More long-term, I always saw the website as a place for such “unversioned docs”, but that could equally live on the new ecosystem pages too - how we organise as a community is definitely part of the ecosystem
For the more volatile part (the list of active groups, their meetings, membership etc), that I see as a forum function - indeed, a link/embed to the Groups page might be all we need.
I’m trying to envision this. So for Foo Working group:
they have a group page (similar to the top-level wiki pages WGs have now)
They are listed in the groups page (and we can remove the list of working groups from docs.ansible.com as a repeat once all WGs are here in the forum)
Working groups that need more detailed documentation/files can add to the ecosystem docsite (we’d have to create a shell structure for them there, so it’s not a dumping ground).
Wondering what @oranod thinks about that use of the ecosystem site…
I was envisioning that place as where we hold the generic docs - how to request a group, what is expected of a group, and so on. I was assuming the front-page of the group (e.g. Steering committee - Ansible) would be the place to document a specific group.
I’m not averse to pages for specific groups, but it feels like we’d repeat the issues with staleness in the repo/site if we’re not careful
Comments (prs etc) welcome on the general structure and instructions in the README etc.
I also have a PR open to edit the old repo README to explain where presentations are moving).
I thought it would be nice to house the presentations in a forum tag/category and have presenters create a new post for each presentation. Discourse supports attachments and provides a place for discussion on the presentation. A standalone repository of slide decks should also work, though.
