Organization Governance #8
Comments
|
Good questions!
Right now, that would be the two owners (me and @JamyGolden). Truth be told, adding someone else made me more than a little nervous - I've been the only active user with commit access to the original spec, schemes, and templates repos and it's a bit of a change having other people who have a say and can override me or take the project in a different direction. However, I understand that in order for the project to outlast one person, there need to be multiple people in charge. This has worked quite well so far (@JamyGolden has been great to work with and they've been a big help reaching out to other repos and pulling everything together), but is somewhat less than ideal when we disagree on a decision because there is no tiebreaker and we're not completely sure what to do. At the moment, for larger decisions, we need to be in agreement - this usually involves us chatting and finding a compromise somewhere. When we have more owners, I agree that majority vote makes sense, but I think that should only be done if you can't reach an agreement or compromise.
The eventual goal would be to have a "primary" maintainer who's responsible for each template, based on how what they've contributed, and how they've helped manage issues, PRs, etc. If they went missing, or there was an problem/major disagreement, it would fall back to the project owners. Ideally all the template leads would be in agreement about the overall vision. This still needs some more details - we're not sure what the requirements for being a primary maintainer would be or when the project owners would have to get pulled in, but the general idea is there. That all being said, this is new to us and we're open to ideas and suggestions. |
Make sense. I agree that it will be good enough for quite some time. I can submit a PR to clarify in readme and consider this issue closed. Does that sound good?
I think we definitely need a "primary" maintainer for each template. But make sure all template are in agreement is hard. Here is what I propose: First, we need a written vision, which is where you guys (kelak, JamyGolden) want to take base16 to. It should not include how to achieve them, since better ideas may come up in the future. We want to make base16 better by having a unified experience for users. And having your template moved to the org will be better because:
But in order to join the template the owner needs to understand:
(FYI To be honest, if base16 moves along and # 5 really happened, we would probably fork the template and majority of traffic will go to the org's fork. But I think that's fine.) As for templates that we feel strongly to be a part of the org but the owner does not want to join or is unavailable. We fork the template. The process does not have to be perfect, but needs to have a clear ownership boundary and be good enough to approach some templates. Now it's becoming more and more like a PR. If it mostly makes sense. I can write a PR for template onboarding doc. And we can address the details there. Does that sound good? |
|
Thanks for taking the time to do this!
Sure, that would be helpful.
This makes sense, but we might not come up with one right away - right now, we're purely trying to take what's already there and make sure it stays maintained. Working on a unified vision will happen over time.
@JamyGolden has been doing a great job of reaching out to other templates. Our vim template was actually from a fork rather than the original vim repo because it was better maintained. Here's an example of how we reached out.
Yes, these make sense. I would actually split 2 into multiple bullet points: "Users can know that the template will receive continued support" and "Work will be put in to make sure the template works with other official templates"
Sort of. Project owners could still step in if there's a disagreement which needs resolving or the community in general doesn't agree with the direction the template owner is taking the template. At the end of the day, the project owner is still transferring their repo/ownership to the org, but they'd be appointed the "primary maintainer" of that template.
Yes, though in general the spec is designed to be backwards compatible for templates.
This is hard to define without having a vision doc (which, as mentioned above, might not be for a while). I'd personally leave this one off.
If the owner becomes unavailable, the org will make decisions for the template. If necessary, the org will appoint a new primary maintainer.
If there's something with no maintainer for an extended period of time, or a template isn't aligned, we'll have the @base16-project-contrib org where people will maintain ownership. I can't think of a reason we'd fully kick out a template.
This does sound helpful, but I think it sounds like something separate from the readme - maybe it should go in a separate file and we could link to it from the README. |
You run into potential weird cases where someone leaves (diff vision) so now you'd have the official For Highlight.js (another OSS project I maintain) we allow 3rd party grammars/plugins to be hosted in the main organization (if they desire), but we also have a global registry (in the organization) that all grammars are added to - whether they are inside org or outside. And everyone wants to be there for the publicity - to make it easy for others to find them.
Ideally. We should also realize that people may have entirely different needs from the project though, for example lets imagine:
One imagines these template maintainers caring about different things:
So I think what one needs from the project is likely to affect how they participate or care about the larger vision... |
i'd also add a one more separate point to this list, for so-called "multi-template builders" (i prefer to call those "universal template builders" instead, as the main point is what they could build any template, not what they could build many templates at same time), as apparent from other threads - this type of apps also having its list of things to "likely to care about" which is different from those of just single-template developers/users |
|
I pretty much agree with all of it @joshgoebel. Except that base9 is not created because the terminal has some different use cases. For your comment about
Are you just making general comments or saying you agree or disagree? I also want to point out that the overall vision should be somewhat accommodating to different use cases. |
|
Obviously builders (single or "universal") are another piece of the "Base16 ecosystem" but I'm not sure I imagine them having unique goals or needs in the same way that templates do... Builders exist to support the templates (and target apps)... Their primary (only?) need is to support the need of templates/target apps. What other needs do you imagine might differentiate one builder from another? Though it may be this part of the discussion should move to #13 where I ask exactly this question. |
I wasn't trying to ascribe primary motivation, but I thought I read somewhere that was one of the reasons, if I got you confused with Base24 or something else you have my apology. |
because they operate on higher level than template itself, ie template don't need to have a knowledge about what other templates are available
doesn't it come obvious itself from the aforementioned "names" - but generally the only difference which should be between builders - is language/technology (ie python lib, js lib, rust lib, shell cli, gui app, etc): my personal belief what all builders should be universal (as it was in the times of base16 before fork) - because format of both templates and schemes is very straightforward for not implementing builders separately for each template type |
You should really weigh in on #13 on this point...
I don't think anyone is suggesting that. |
Yeah, I agree. I'd like to avoid this unless there's a specific reason (there were a few binary templates a while back which sort of needed a custom setup, but other than that there's no real reason)
@actionless I think "builder" is an overloaded term, even if you add "single" or "universal" as a qualifier. I think the terminology we're thinking of settling on is "builder" (what you're calling a single builder) vs "manager" (a sort of universal builder/manager). This is still stuff we're figuring out - in any sense, I think another issue (like #3 or #13) would be a better place for this part of the discussion to continue. |
|
if you prefer to call it "template manager + template builder" instead of "universal template builder" - i really don't mind just the point that the aspect of "template management" should be described in a spec as it was before - i don't really see potential problems if making it "optional" so developers of builders would not be obligated implementing it anymore |
|
@belak Was someone actually asking for a manager, or did we just invent that as a "cover all bases" sorta-thing? Or did that only come up after you simplified the builder spec? |
The term is invented. There were people asking for a way to programmatically get all templates - that was what I was hoping to solve in this issue.
Yes, it only came up after the simplified spec was merged in. |
|
i think it originally "came up" at the moment before/when it was originally implemented in Chris's base16 - it's aparent what it was just mistakenly removed together with similar infra for schemes, which is not needed anymore after merging all schemes to single repo |
|
Found this to be pretty interesting read. It talks about how governance works for another project. Any reason we shouldn't copy over and just add our twist for base16 specific stuff? |
|
I'm closing this in favor of #84, where we're collecting all remaining project management related questions. |
Having a clear governance model will ensure a clear vision for the project. Here is what I'm thinking:
Who has the final say about the project?
I think it's probably one or a group of people (Let's call it owners). If a group of people has disagreement, it's decided through a simple majority vote. Owners can always delegate decisions on certain areas to certain people, but owners can always take that back.
Do you guys agree?
If so, who are the owners right now? And when you say you are looking for collaborators, are you open to adding more owners?
This is a potentially dangerous decision, since if you add more owners, they are able to override your decisions and potentially even throw you out.
Who has the final say about each template and each repo under the org?
I think it should still be the base16 owners. Since the whole point of having an org is to centralize things and have a coherent vision. If that's the case, we should really be clear about that when a template wants to be in the org. If the original owner does not want to give up the ownership, we should advise them to continue to be "unofficial" base16 templates, etc.
Do you guys agree?
The text was updated successfully, but these errors were encountered: