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
(site) add site from ned-kelly/libretime-website #584
Conversation
I have a branch prepared at master...radiorabe:chore/integrate-site that preserves @ned-kelly's edit history. I think we should onboard him as a Maintainer as well so he can continue maintaining the page. I also didn't find time to integrate his |
sweet!
big +1 to adding @ned-kelly as a maintainer. @Robbt cómo ves? i know i haven't been involved in the project for nearly as long as others, but will share my opinion here anyway :). I'd love to arrive at a consensus that reduces dependence on you Lucas for non-RelEng stuff since i think we could definitely move faster as a project. I think we could better distribute tasks between maintainers without negatively impacting the quality of the product IF we had well-understood consensus about responsibility for specific tasks. Things would be accomplished differently (eg. for the site i'd probably just commit processed css files instead of researching how to get node into travis), but hopefully the final product wouldn't suffer, and input from all would still be possible, just asynchronous (oops geekspeak). For example, if I had had 1. permissions to create repositories, and 2. group consensus, I would have already made progress on docker with ned (see slack thread), and also the site. thanks! |
I'm onboard with @ned-kelly becoming a maintainer. I am excited that we are growing the project. I'm not sure how to do all of the stuff behind the scenes as far as github goes, but it might make sense to have a maintainers coordination discussion. We could do it on here, via RT chat (might be tricky considering the timezone differences) or on the forum. I think the trickiest thing at this point is figuring out who is going to do what. For instance in this particular PR should we redo it to include the commits in @hairmare added and if so what exactly are the steps to do this. |
consensus! could you go ahead and do this @Robbt ?
definitely. very necessary. weekdays in the mornings (CST, or UTC/GMT -6 hours) are generally best but i can be flexible. perhaps in slack? are audio conference calls possible in slack?
i personally don't think the site commit history is necessary. Ned's docker repo is however a different story -- with both a meaningful commit history and issues that would be good to keep. take care everybody! |
Great, I sent the invite to @ned-kelly I personally think that the commits might be useful to show what changes were made from the default template but it probably isn't too important. As far as transferring issues it appears that just last month this was added to Github beta so I think we can probably use it - see this discussion and here's the doc |
I just create a PR with @hairmare work that retained the @ned-kelly commits at #590 - since that was easy to do. I'm not sure if it is ready to merge as it includes some work on the travis CI config. If we decide to merge that we can just close this one. |
awesome! closing this one.
my understanding of @ned-kelly 's suggestion is to simply transfer the entire repo. however he'd need repository creation permissions. would that be a problem? i think maintainers team members currently do not have that permission: thanks! |
It looks like in order to give @ned-kelly the ability to do this we would need to enable it for all members since he is not an owner and there doesn't appear to be a way to just give this permission to members of a certain team vs. all members at least from my limited research. We could do this temporarily so that it could be transferred and then turn off the permission after it is done. In general "membership" is pretty open vs. membership on a specific team. It is also possible that I just couldn't find the right way to say give maintainers only the ability to create repositories (which I figure would be ideal). |
baddass. thanks for the research @Robbt . i'd say that if @hairmare can't
answer this weekend then it'd be good to do whatever you see fit to get us
past this bottleneck. for my part, i'm chill with whatever. sorry to be of
zero help with the github stuff.
…On Sun, Nov 11, 2018 at 11:27 AM Robb ***@***.***> wrote:
It looks like in order to give @ned-kelly <https://github.com/ned-kelly>
the ability to do this we would need to enable it for all members since he
is not an owner and there doesn't appear to be a way to just give this
permission to members of a certain team vs. all members at least from my
limited research. We could do this temporarily so that it could be
transferred and then turn off the permission after it is done. In general
"membership" is pretty open vs. membership on a specific team. It is also
possible that I just couldn't find the right way to say give maintainers
only the ability to create repositories (which I figure would be ideal).
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#584 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AjGSQdcP3ef0s-J8Xfkt29o5K8ZBFzd3ks5uuF4TgaJpZM4YM2wj>
.
|
https://github.com/ned-kelly/libretime-website doesn't seem to have any issues on it. Did I miss something that didn't make it into #590. IMO #590 looks great and is waiting for @ned-kelly to return from his holiday so we can focus on reviewing and landing it. I already rebuilt the travis parts and there is some potential to get rid of the included dependencies since the build process will redownload them anyway. |
straight from https://github.com/ned-kelly/libretime-website