Я запускаю проект с открытым исходным кодом. Совет? [закрытый]

имейте в виду, Что Вы измеряете, то, что Вы получаете. местоположение ничего не говорит о производительности или efficency.

оценивают программиста строками кода, и Вы доберетесь.. строки кода. тот же аргумент идет для других метрик.

otoh.. http://www.crap4j.org/ является очень консервативной и полезной метрикой. это устанавливает сложность в отношении с покрытием.

5
задан Community 23 May 2017 в 10:26
поделиться

7 ответов

If you're looking to build a community, it's not always about the tools, more about the processes you can use to build a community. There are plenty of people who will use whatever tool you give them or will choose (or refuse) to participate in a project based on the tools, but if the community stinks very few people will hang around.

I'd recommend spending some time thinking about how you're going to embrace a community. Are you ready to take the time to respond to bug reports? How will you handle enhancement requests? Are you willing to let something into the code if several people want it, but you don't? These are all critical issues that in the end will be far more important then Assmebla vs Trac.

You may want to check out Karl Fogel's book Producing Open Source Software or Jono Bacon's The Art of Community for more hints on managing and building a community.

5
ответ дан 18 December 2019 в 13:15
поделиться

First, big obvious download buttons so that a person can download your project, make it just plain easy. Secondly, forums so that people can give you feedback good and bad about the project.

Good luck on your project!

2
ответ дан 18 December 2019 в 13:15
поделиться

I would suggest checking out this book: http://producingoss.com/

I believe there is a free online and pdf version.

I have messed around with Trac some and it can certainly get the job done but if you are already doing an agile development process I would check out Pivotal Tracker. I use it on a side project and it's pretty slick, not to mention free to use. Pivotal has all the things you would expect: stories, backlog, velocity calculation, a few charts, etc.

2
ответ дан 18 December 2019 в 13:15
поделиться
  • Strive for adoption. The more users you get, the more people will contribute back.

  • Include lots of code samples on the wiki and let users download a sample application.

  • Make sure your API is well-documented with ASDoc.

  • Provide a roadmap to so that potential users can see your direction and intentions.

  • Be diligent about prioritizing feature requests and bugs. You and your team don't have time to do everything.

  • Make integration as seamless as possible. Hopefully users will be able to simply download a .swc (Flash library) and link it into their application.

  • Release early, release often. I hate having to download and use the HEAD revision from a repository because a team has only officially released one version of their project and it's a year old.

2
ответ дан 18 December 2019 в 13:15
поделиться

To me, guiding the development is more a matter of prioritizing what has to be done so I'm tempted to say: why don't you just use Google Code issue tracker as your project is already hosted there? I think it's offering all you need. Customize it to add a Estimates field if you want (for Scrum) and there you go.

Why do you think you would need something else? You already have a source repository, code reviews facilities, a wiki, mailing lists, an issue tracker, secured access for contributors. You don't need much more for collaborative work. What are you missing? Instant Messaging? Use Skype or Gtalk. IRC? You don't need it for now. No, really, I don't think a tool is gonna solve anything more here (even if you can't draw your burndown chart, not a big deal for a non full time project IMO).

So, because any other tool would be less well integrated with other Google Code services (e.g. I like to link my commits to issues using "Issue #ID" in comments which is automatically linked), I'd stick with what you currently have (maybe just add Gtalk/Skype to ease the communication/collaboration) and I'd start creating issues and prioritizing them. Good prioritization of work is the key to a successful project, there is no silver bullet tool that will do this for you. Then, plan fixed date milestones (releases) and assign most important issues to the upcoming milestone. Close as many issues as you can before the deadline. When the release time has come, release what has been done, postpone non implemented issue to the next milestone and start again.

2
ответ дан 18 December 2019 в 13:15
поделиться

Don't host your code on codeplex. I recently started an open source project as the basis of an article series on DotNetSlackers.com to show people how to build a site like SO. I mistakenly hosted this project on CodePlex. My automated build will periodically send me broken build emails as CodePlex will randomly go down for hours at a time. IT DRIVES ME NUTS!

If you plan to develop code that is free to the world but don't plan on letting anyone and everyone submit code to your project...host your own source control (perforce is free for a couple of users) or use something like google to host your code.

0
ответ дан 18 December 2019 в 13:15
поделиться

Если вам нужно программное обеспечение для поддержки вашего проекта Scrum ... agile42 предлагает бесплатные лицензии Agilo for Scrum Pro для проектов с открытым исходным кодом.

1
ответ дан 18 December 2019 в 13:15
поделиться
Другие вопросы по тегам:

Похожие вопросы: