Off the top of my head, the list of languages the Eclipse IDE supports. The list of common features. The list of other IDE add on features such as team and application life cycle support.
Plus the regulars like pointer to downloads, how to contribute, etc.
Doug and I had a very short exchange on Twitter regarding the need for an "Eclipse IDE" page that targets end users specifically. In my mind, this is directly related to the packages.
Currently the closest thing that we have to anything like this is the downloads page.
What would an "Eclipse IDE" page contain?
Wayne
On 07/15/2013 09:59 AM, Andrew Ross wrote:
+1 to code sprints (aka. hackathons) and what Andrew is saying here.
Face to face events, and especially code sprints are a great way to make human connections and build trust in the community. It is so easy to overlook how crucial this is for newcomers. Bringing them into the community is battling against a very easy choice
to simply walk away.
Tools and process have to be "just right" to balance properly. But you can have amazing tools and if people just aren't inspired, or if people inadvertently get turned off by lack of engagement even awesome tools won't fix that. A buffer of trust built by face
to face contact can help a lot to forgive inevitable misunderstandings, delays, PITA's, and other issues that crop up.
On 13/07/13 18:06, Andrew Eisenberg wrote:
I'm not saying this is THE answer or anything, but it may be a small step towards getting more contributors and outside participation.
We've been holding hackathons instead of demo camps for the past couple of years and they've been well attended (20-30 people) and at the end of the evening we have had 4-5 patches that are good enough that with a little polish can be contributed to the code
base. Granted, we haven't had any long term contributors or committers come out of this, but at least it is introducing newcomers to open source and the Eclipse community. I've generally found the experience more rewarding that the demo camps.
It's still a bunch of work for the project leads: making sure the getting started docs are up to date, and finding/creating a bunch of bugs suitable for newcomers, etc. But this is something that is a lot of work up front and then it pays off over the long
run.
This is not a way to get people to fix the hard bugs, and it's not really a way to save work for project members (since any bug that a newcomer can fix in an evening is something that a project member can fix in a couple of hours). What this really does is
bring life into the community and make it seem like Eclipse is not "dead". And maybe over time, if enough hackathons are held, this is a way to slowly turn people into committers.
regards,
Andrew
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|