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
Initiatives: create plugin declaration #1416
Conversation
Based on the missed eslint thing, made sure to fix my sublimelint extension. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, we do like having small semantic commits. Usually the way @wchargin and I do it is to build a stack of commits all pointing at master, and only merge commits as we become confident that we won't make more tweaks based on the yet-unmerged feature work. I'll let @wchargin comment on the idea of using feature branches.
*/ | ||
|
||
/** | ||
* A Discourse topic (src) TRACKS (verb) an initiative (dst). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed here, I don't think we need a separate edge for this--we can consider the Discourse topic which defines an initiative to be an implicit contribution towards that initiative.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've removed the edge type for trackers. Instead the idea is trackers will be added as a contribution. Using the editor to lower the weights in cases where the tracker doesn't provide much value in the form of discussion for example.
So, for instance a later change like "remove the 'tracks' edge after all" instead would be to go back to these commits, modify it to look like it never had that edge type, rebase everything else, and only merge the whole thing until we're ready for the first iteration of the incentives system? In this case ece89a3 may be an example of where you'd want to go back and "swap out" the declaration commit instead of building on top of it? |
ece89a3
to
4779808
Compare
I think this setup now has the right idea for commits right? I've incorporated some feedback and included the "Missed the final declaration, tripping eslint." commit as well. Edit: saw from @wchargin's PR that changing base branches is a thing. So this + #1417 should be that setup? |
Including feedback/fixes from #1416 - Rephrased comment. - Include the final declaration.
Including feedback/fixes from #1416 - Rephrased comment. - Include the final declaration.
Including feedback/fixes from #1416 - Rephrased comment. - Include the final declaration.
Including feedback/fixes from #1416 - Rephrased comment. - Include the final declaration.
Including feedback/fixes from #1416 - Rephrased comment.
Including feedback/fixes from #1416 - Rephrased comment.
4779808
to
1608761
Compare
I've removed the readme from this PR, as it doesn't offer much value at this point anyway. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good, with the following nit: I've thought we would call it the "initiative" plugin rather than "initiatives" plugin. Any particular reason to go with the pluralization as the plugin name? (I recognize it doesn't matter that much, hence the approval anyway)
Not really. Overall there seems to be inconsistency in this regard when looking at filenames. There's plural
There's singular
From the readability of an instance configuration file I feel like the plural fits slightly better. plugins:
- github
- initiatives Could be turned into a question. That said, I don't really care either way :P |
Including feedback/fixes from #1416 - Rephrased comment.
1608761
to
d8a28e5
Compare
Though the weights may still be subject to some balancing, pretty confident about this declaration. |
Creates the declaration for the initiatives plugin and includes a readme.
If I understand CONTRIBUTING.md correctly, the idea is to have lots of small PRs.
Not sure if you prefer to merge the unused declaration into master, so right now I am targeting a feature branch that the semantically atomic commits can accumulate into.
I've also included rationale for the edge weights.