I ignored the snakecase lint warnings because the entire style inside ArcanistTextLinter is camelCase.

https://secure.phabricator.com/book/phabcontrib/article/php_coding_standards/#case-and-capitalization

Can I add ¯\_(ツ)_/¯ to the project README and update .arclint to support UTF8?

@chad So I should ignore the convention currently in the file for all new additions?

I'm not sure what you're asking. Lint is raising errors and you should fix them, lint is correct, per convention. If the file is incorrect somewhere, I can't find it.

@chad resolved lint warnings.

*bump*

See Planning

@chad Forgive me if I misunderstood, but is that document suggesting that I need to pay to get a diff reviewed and accepted?

I understand paying to get a new feature implemented or getting a diff reviewed ASAP, but it strikes me as odd to pay if I've provided free labor to implement it myself and the feature is a very reasonable and broadly useful feature (in addition to my use case, my diff also allows customers in many foreign languages to use characters from their language in their READMEs and other text documents). I could see paying as reasonable if I want this done ASAP, but I just want to get an idea of when this might be accepted.

That link says you should not ask "when are you going to do X", because the answer is "we don't know".

You may also be interested in https://secure.phabricator.com/book/phabcontrib/article/contributing_code/.

Sorry I read that differently. I though that was only addressing when you might build a feature, not when you might review a feature. In my mind (having maintained projects myself), asking a maintainer to build something new is very different from asking for review of something someone has already implemented. The former is the request from someone who takes and doesn't give back and the latter is someone who is (usually) working towards the same goal of making something better and can be a valuable productive member of the community if their interest in the project is nurtured.

Should I assume that the answer to "When will you review a diff (for some feature)?" is the same as "When will you build (some feature)?"? Or are diffs treated differently than feature requests?

Thanks for that second document. I didn't find it earlier.

I'm just the designer, so I can't review this for you. I don't have any idea when it may be reviewed, but it won't likely be immediate, which the documents @avivey listed should explain. Since we're only 2 people full-time on a large project, we do our best to stay focused on current roadmap items and only look into non-priority stuff as we have time.

In general contributions are not free for us. That is, when we take code, we're expressly taking over ownership, maintenance, documentation, and support for life. We don't expect you to maintain the code moving forward, or be in IRC answering questions. In most cases support is significantly more in cost than the original code written. We do love contributions though! But we'll usually be a bit more thoughtful and thorough in what we bring upstream due to these costs.

We generally want tasks opened first before code so we can decide if code is even needed, if it should wait for other infrastructure work, or if we should do it ourselves given complexity.

You may find T10038 interesting as well.

@avivey Maniphest ticket filed: T11150

@chad thanks for the information and the link to that task.