-
Notifications
You must be signed in to change notification settings - Fork 229
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
Internal Communication #1491
Comments
Thanks for opening this Adam. We all work differently and need to respect. I'm convinced that GitHub has sufficient options with notification unsubscription, muting, and following to get to a situation that fulfills most needs. Perhaps then before we fragment this board we should do a little requirements analysis: a) find out precise details of what people want in terms of internal comms. |
I think one solution would be assigning people or teams. There are many issues that I simply do not read because I am not mentioned or because they are not assigned to me -- thus I do not get any notification to my email account (side note: should I change my notification parameters? If so, I will get too many perhaps...). I often check Github notifications panel but not every day... I only belong to the Spanish team at the moment but I want to keep updated about other's people decision because they really affect my work as editor - plus I want to identify with the project as a whole although I am doing only editing tasks at present. |
I know people don't like surveys and many don't respond to them but, could we start by asking every single one of us about the settings they have? Are people unsubscribing from notifications? Is there a way to have a weekly feed from Github instead of individual emails per comment/issue? Could we implement something like https://github.com/apps/weekly-digest This comes from
Personally, I have all notifications ON and I simply browse through the emails to see what is going on, then I delete the emails, respond, work on something if I'm assigned to it, etc. It is overwhelming sometimes, but I like being informed |
I have a very different approach from @jenniferisasi. I relentlessly unsubscribe from particular issues because there is too much chatter on any active repository to keep up with every discussion (this has been the case on every project I've worked on). If I know it is a topic that I don't have an opinion on, I know that I will defer to the people who are engaged with that topic. The new team structure is helping to facilitate that. GitHub is set up so that I'll still get an email if I'm mentioned in a thread though, and I try to respond to those things quickly. The project's complexity is such that I think it's difficult to imagine anyone really keeping up with the workings of all the components. The system I have set up reflects that, and I can always go back and read through all the threads if I want (I usually do it while we're on our skype calls so I can remain updated). But the different options in GitHub are set up so that one should be able to personalize your own settings in a way that you'd like. It works for me, but I know it might not work for everyone. |
Thinking about @arojascastro, I think it is possible to subscribe to tagged tickets. So, for example, you wouldn't miss a 'policy' ticket (which we use for substantial changes only) if you were subscribed to that. Am I right? |
Yes, I guess I can subscribe to certain tickets according to the label.... but that means checking every day Github. Anyway... Which labels I should care about? |
Thanks for the comments on this. I appreciate that there can be too much to keep up with at times. And it seems like some people are opting out of following certain threads (or everything in a few cases). The challenge becomes with how we can proceed with decisions if some or even most people don't care, but don't let us know they dont' care. For example, if I'm waiting for input on What Business Models We're Happy With #1487 and you don't care so you don't respond, but you don't tell me you've looked at it and decided you don't care, then I'm waiting at least a month until our next call in order to be able to take action. So how do we balance this desire to let everyone contribute to decisions, with a need to make decisions efficiently and take the project forward in a timely manner? |
@acrymble: I like @jenniferisasi's idea as a starting point. |
A weekly digest would be cool! I confess I prefer receiving emails with a selection of tickets that need feedback from all the members. |
So have we installed an App on the project before? It looks like there is an app for 'work in progress' and we have the project-tracking tab/feature but I'm not sure if that one is an app or simply a regular GitHub feature. |
Speaking only for myself, my understanding of the team organization was that I have opted into the teams where I feel I have the most contribute and will be the most engaged. My understanding was that the whole point was to delegate decisions in other areas to those people who had opted into interest in those areas. And we have the policy tagging system for setting a deadline for getting feedback before a particular time for decisions that we need to move forward. |
Yes, you are probably right @walshbr -- I support @jenniferisasi proposal about a survey, but maybe we do not get any answer... who knows? |
@walshbr so if I understand, you're saying it might be more appropriate to say "this is what we're planning on Team X and we welcome your feedback if you have any" rather than an approach that seeks permission or consensus before starting? |
Yeah I think that might be what I'm suggesting @acrymble. Think of Team X as first point of feedback (it's a smaller number anyway, so easier to track if people are or aren't weighing in), offer news and ask for input at the calls if necessary, and lift anything to the level of a policy tag if you feel it merits it. That seems like an efficient use of the team structure, and there's nothing stopping interested parties not on a particular team from weighing in on a ticket after all. |
Reminder of our Governance Policy with the specific path for
|
From #1483 suggestion that heads of teams update this guidance to fit new team structure. |
@drjwbaker what's the action item here? Each team should be adding text to the wiki Governance page? Or...? |
Yes, heads of teams need to do this #1491 (comment) |
@jenniferisasi Is there anything actionable you want to take forward from this ticket? |
Yup!
El El mar, 12 nov 2019 a las 10:41, Jennifer Isasi <notifications@github.com>
escribió:
Shall we implement kanban boards for all teams as started by @svmelton
<https://github.com/svmelton> and suggested by @acrymble
<https://github.com/acrymble>?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1491?email_source=notifications&email_token=ABYAAT2XN3HHB253GVMXUH3QTLFDBA5CNFSM4I63SNYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOED2VLWY#issuecomment-552949211>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABYAATYRAM2KJJP3WXSGDO3QTLFDBANCNFSM4I63SNYA>
.
--
Enviado desde mi móvil
|
Should we phase in the kanban idea slowly so that we can work out any problems? @svmelton would you be happy to work with one team at a time to help them set this up? Maybe the @programminghistorian/french-team is good place to start since the tasks are the same? |
Happy to work with the @programminghistorian/french-team! It might make sense to have someone from that team start drafting up a board and ping me if they run into any problems. |
I am closing this on the assumption that we are taking it forward with #1546 Kanban boards. |
Our team satisfaction survey and a number of recent conversations have shown that our internal team communication channels have become ineffective. There are too many threads happening, and most people are unable to keep up. The impact of this seems to be that many team members have stopped reading and thus keeping up with project developments. Changes that have been openly discussed can seem like they came out of the blue if you haven't been reading.
I believe we need a new plan for internal communication and a rethink of how we use Github tickets. Whether that's a new github board for each team, or something else entirely, I don't know. But I think we need some suggestions for balancing our open decision making with information overload. Please share ideas.
The text was updated successfully, but these errors were encountered: