Skip to content
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

Define project goals #44

Closed
commonquail opened this issue Jan 29, 2014 · 6 comments
Closed

Define project goals #44

commonquail opened this issue Jan 29, 2014 · 6 comments

Comments

@commonquail
Copy link
Contributor

Without wanting to overwhelm @afaqurk with bureaucratic busywork, having some concrete goals (or non-goals) listed in, say, the readme, will make contributing easier. Two specific questions I'd like answered are targeted PHP version and targeted browsers. The former is obvious -- in case of the latter, targeting only recent browsers (which I'd personally suggest as reasonable considering the target audience) may allow for simplifying parts of the code (mainly CSS). Something else to consider could be what platforms are of interest but I don't personally have a stake in that.
This can be extended to include stuff like coding style or expectations of tests where applicable.

Primarily, what does afaqurk want from this project? Secondarily, what does everyone else want?

@tariqbuilds
Copy link
Owner

You are absolutely on point @commonquail. This has been on my mind the last few days as the project has taken off a bit.

I have very specific ideas and goals in mind and I am finalizing the list privately right now. I am very structured in my software development and that will be reflected in the development roadmap and project goals. Look for this shortly.

I welcome input on this from everyone.

Thanks everyone!

@commonquail
Copy link
Contributor Author

I don't expect to have anything surprising to add but for my own selfish purposes:

  • Where I use this I'll have PHP 5.5 but 5.3 is the reality many places. 5.5 would be nice but may not be practical.
  • I only need to worry about the latest Firefox and Chrome. I would be able to lose some vendor prefixes.
  • Also, GNU/Linux, but that's already the case.
  • Adherence to a formal style guide that can be checked with something like CodeSniffer is a pragmatic concern that can eliminate any discussion about this at-times contentious issue. I'd do it for this reason alone and less so because I'm anal retentive (though I totally am).
  • I'd argue for tests at least when and where it makes sense.

@ghost
Copy link

ghost commented Jan 29, 2014

I am also looking forward to some guidelines, @afaqurk noted on a pull request(#37) i did that linux-dash is intended to run locally. I can see myself using it over the internet for quick checks tho.

Edit: i had a quick read and misinterpreted it. Further discussion will be posted on the the following issue #25.

@andrewicarlson
Copy link

@afaqurk, I would be interested in getting involved with this project. I'm looking forward to some goals to ease the process of beginning contribution!

@tariqbuilds
Copy link
Owner

Please see the Wiki for the working copy of the project goals and documentation template.

Also, several milestones have been added to the project, which outline the road-map to v1.0.

Thanks!

@tariqbuilds
Copy link
Owner

Please refer to README / Wiki for all documentation, project goals, and contribution guidelines.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants